cybadger

Thank you for the feedback!

I've certainly been misunderstood more than once. I've also misunderstood people who thought they were being perfectly clear.

That particular example is intended to be an example of a well-intentioned manager sending a message but it not being received. Maybe it's time pressure, or an interruption, or just bad wording. "Y'all, we need to change 'Login' ...oh, hang on, I need to take this call."

The next paragraph is an example of exactly what you're talking about—where the team shares information with the manager, the manager learns something about the system, and it leads to improved trust between team and manager.

I think you're taking "there's a good chance your team didn't understand what you told them" to mean "your team is so dumb they don't understand basic words and you need to correct them". It's meant as a value-neutral description of something that's really common in human interactions: someone tries to communicate X, but what's received is different than X. In this case, that's on the manager to fix.

So...how could I edit that paragraph so it comes across better, without trying to incorporate some of the things that came before (admit you're not the expert, ask questions, etc)?

I could make it even more ridiculous: > For example, if you just asked them to change the text on the "Login" button, and they're talking about how that means upgrading the load balancer and switching to a NoSQL database, there's a good chance your team didn't understand what you told them.

I could try to make the error attribution more obvious: > For example, if you just asked them to change the text on the "Login" button, and they're talking about new libraries and rewriting the credential store, there's a good chance you didn't communicate what you thought you did.

I could add some corrective actions later on: > For example, if you just asked them to change the text on the "Login" button, and they're talking about new libraries and rewriting the credential store, there's a good chance your team didn't understand what you told them. Take the time to make sure they understood correctly. If they did, you've got something to learn.

I think you're railing against the exact sort of thing I'm working to fix here: people who think their title means they don't have to listen to their team, or that they're automatically an expert because of their title, or something. So your input on how to make it land with you (because it obviously didn't as originally written) would be helpful.

Mgr: "I need you to plan travel to LA."

Dev: "Cool, got it."

(Having been that dev, wrong! Don't got it. Which is why, as manager...)

Mgr: "I need you to plan travel to LA. For the six of us. Planning to leave tomorrow before lunch. What questions do you have?"

Dev: "Do we have a budget or cost restriction? Is there a time we need to be in LA?"

Mgr: "Let me double-check the budget and get back to you in a few minutes. We're supposed to be in LA by 6PM tomorrow."

(Other good what-if scenarios could include that meeting the travelers are supposed to be in all afternoon tomorrow, whether everyone needs to travel together, where the group is leaving from, if the Dev should book travel or just send a plan, ...)

All of those things help shape the approach, the details, the implementation.

Because, without clarity, some manager who's not an expert and hasn't asked the right questions will say "yeah, sure, we can use the plaintext credential store Bobby threw together, it's fine, get it done fast".

When the manager is invested in creating clarity for the team (which is not the same as barking out orders or trying to "get the 'throw' done as quickly as possible), they'll take the up-front time. And when Bobby says "hey, look, plaintext credential store!", the manager can point back to the approach the team put together (e.g., salted, hashed, ever stored/logged in plaintext, etc).

Reading between the lines, it sounds like you've seen some pretty bad management, probably with a lot of short-term thinking and disrespect for "inferiors". That sucks. I've had some terrible managers too, along exactly those same lines. But I've also had some pretty good managers too. I've found that a lot of managers are terrible because they don't know better. They don't know how to support a team, or how to be clear, or how to listen. And a lot will make improvements when given some help.

What I dislike about the original post is that he seems to think his job is to lead and have them follow.

Can you help me understand what in the original post came across that way?

Sure, managers do have a responsibility to lead their team, and they're held responsible for the results their organization team produces. That's the job. It'll look different company by company, of course. But I definitely didn't have some kind of command-and-control management approach in mind.

It isn't. His job is to support, to do the things, manage the interactions, that are preventing the team from working effectively.

I agree! Like I wrote toward the end of the post, "The real secret of managing an expert team when you can’t do their jobs is to give up the illusion that you have to be superpowered and all-knowing. Instead, you can be the manager, supporting and directing your team, making sure you deliver results through your team."

That sounds—to me, and I might be missing something—pretty similar to what you're advocating.

Author here. Yes, if you don't know the domain, you should have a really good reason for overriding the team.

Asking questions is a way to gather information that you can then share back with the team. If I were new to a team and had a situation like what you describe, I might go back to my team: "Hey all, I was talking with Professor SmartyPants about $PROBLEM and they suggested $APPROACH. It sounded plausible to me, but y'all are the experts here. Is $APPROACH something we've thought about, and can you help me understand the pros and cons?"

The discussion that follows would help me figure out how good folks on my own team are: who considers the idea, who can explain why it's good or bad, who gets huffy when new ideas are brought.

So yes, 100%, be careful with thinking "I asked questions of a lot of people" means "now I'm an expert that should override what my team is telling me"!

  Location:  Iowa, USA
  Remote: Yes
  Willing to relocate: No (\* yes for amazing opportunity)
  Technologies:  C#, TypeScript/JS, Python, Ruby, Azure, relational and document DBs, DevOps,...
  Resume/CV: 20+ years engineering, 8+ of those in management roles.  Contact for resume.
  Email:  matt.schouten@gmail.com

I'd also be interested in (and good at) fractional / consulting work or team coaching.

I do my best work as a strong #2, supporting a leader that values ideas and feedback, whether in a management or IC role. (Working Geniuses: invention and enablement. Working Frustrations: galvanizing and tenacity)

   Location:  Iowa, USA
   Remote: Yes
   Willing to relocate: No (\* yes for amazing opportunity)
   Technologies:  C#, TypeScript/JS, Python, Ruby, Azure, relational and document DBs, DevOps,...
   Resume/CV: 20+ years engineering, 8+ of those in management roles.  Contact for resume.
   Email:  matt.schouten@gmail.com

I’m a builder and coach at heart, and will happily build software, do product development, architect systems, or step into a leadership / management role. That said, you don’t want me to be your interface designer, but I can implement someone else’s design just fine.

It seems I do my best work as a strong #2, supporting a leader that values ideas and feedback, whether in a management or IC role. (Working Geniuses: invention and enablement. Working Frustrations: galvanizing and tenacity)

SEEKING WORK | Iowa, USA | Remote

Hi! I'm Matt. I solve team problems: individual issues, teamwork, cross-functional collaboration, delivery, workflows.

Looking for fractional / consulting / coaching work helping managers (directors, etc) or high-performing ICs.

I've delivered disproportionate value in helping solve issues with quality, delivery, collaboration, attrition, and org design.

I've also helped managers/leaders upgrade their systems and behaviors to get much better results out of their team with a lot less work.

  Email:  matt.schouten@cybadger.com
  Site:  https://cybadger.com/coaching

SEEKING WORK | Iowa, USA | Remote

Hi! I'm Matt. Good at solving problems with teams that blend organizational and technical.

Looking for fractional / consulting / coaching work helping managers (directors, etc) or high-performing ICs.

I've delivered disproportionate value in helping solve issues with quality, delivery, collaboration, attrition, and org design.

I've also helped managers/leaders upgrade their systems and behaviors to get much better results out of their team with a lot less work.

  Email:  matt.schouten@cybadger.com
  Site:  https://cybadger.com/coaching

  Location:  Iowa, USA
  Remote: Yes
  Willing to relocate: No (\* yes for amazing opportunity)
  Technologies:  C#, TypeScript/JS, Python, Ruby, Azure, relational and document DBs, DevOps,...
  Resume/CV: 20+ years engineering, 8+ of those in management roles.  Contact for resume.
  Email:  matt.schouten@gmail.com

Hi! I'm Matt. Good at leading teams, good at hands-on problem solving. I don't particularly care about the title. Looking for a technical leadership role (e.g., Director/Sr Mgr Engineering, or Senior/Staff Engineer, depending on whether it's management or hands-on).

I'd also be interested in (and good at) fractional / consulting work or team coaching.

I will add a third claim against it: all that black and gold. As an Iowa State grad, there's a certain arrogance that the University of Iowa undergrads give off (grad students and faculty seem to be fine). [For those not from 'round here, U of Iowa and Iowa State are the two largest universities in the state. There's a healthy—and occasionally unhealthy—rivalry.]

That said, I do actually really like the town itself. Like you said, active, friendly, with a real vibrancy to it. I don't get there often (strange, since Cedar Rapids is not that far away), but enjoy it when I'm there.

‎‎

  Location:  Cedar Rapids, IA
  Remote:  Yes, preferred
  Willing to relocate:  Only for an exceptional opportunity
  Technologies: C#, Javascript, Python, SQL, Docker, CI/CD pipelines, Azure, testing, the written word, and many others
  Résumé/CV:  upon request; LinkedIn:  https://www.linkedin.com/in/matt-schouten-3b544b7/
  Email:  matt.schouten@gmail.com

I’m a builder and coach at heart, and will happily build software, do product development, architect systems, or step into a leadership / management role. That said, you don’t want me to be your interface designer, but I can implement someone else’s design just fine.

It seems I do my best work as a strong #2, supporting a leader that values ideas and feedback, whether in a management or IC role. (Working Geniuses: invention and enablement. Working Frustrations: galvanizing and tenacity)

[Also available for manager / leader / developer coaching.]

Updating to add the Onboarding Algorithm post I mentioned above. https://www.cybadger.com/2023/06/04/the-onboarding-algorithm...

A lot of what is in this thread is excellent. I'm actually working on a fairly detailed HOWTO for creating a custom-fit onboarding program (send me an email and I'll send you a draft; I'll update here when it's ready for public consumption). Here are the key principles:

1. Know what you want the employee to do, and equip them to do it. (This covers things like shipping the laptop ahead of time, getting accounts set up, planning tasks for them when they start...)

2. Help the new employee feel supported. (Item #1 relates to this, but it's also things like welcoming them on their first day, assigning a buddy, giving them a tour of your company / application / industry, making their initial responsibilities clear...)

3. Have a plan for bringing them up to speed. They need to get to know the job itself, the company, the people, and that all takes time. Work sequencing is important in building a product. It's even more important when it comes to integrating a person into a complex network of activities and other people.

In all those items, the ability to put yourself in the new hire's shoes is essential. It's easy to forget how much you know about the job, the company, etc., that you end up giving them tasks that feel small, but that are daunting to them. That said, taking time with the new hire regularly over their first couple of weeks and building a good working relationship can help calibrate, and help smooth over any potential issues that come up from being miscalibrated.

Also, a couple posts I've written about onboarding might be helpful:

- https://www.cybadger.com/2022/07/02/a-tale-of-two-onboarding... is a reflection on two onboarding experiences I've personally had

- https://www.cybadger.com/2022/10/11/onboarding-gis-technicia... is creating a better onboarding experience for a non-developer role, but the principles are the same.

Seconding Manager Tools podcasts. Use their "Map of the Universe". Professional Success -> Professional Skills -> Meetings gets to most of the meeting casts.

Having an agenda and sticking to it plus setting ground rules helps a lot, whether it's remote meetings or in-person.

https://manager-tools.com/map-of-the-universe#269

Agreed, especially starting with Working Effectively with Legacy Code.

One of the hard things about what we're assuming is OP's tech lead role is that they're having to influence changes up (with management) and down/laterally (with the team). Things that might convince the team are going to be generally different than the things that might convince management. Management will probably be more convinced by things like improved lead time for changes, eliminating risk of failure, improving confidence in correctness of feature roll-out (though some of this depends a lot on the industry / domain and the incentives of management). Meanwhile the team will be more convinced by things like making their job easier or setting themselves up with more and better skills to take a "better" job down the road.

The rub with all this is that if the team doesn't like OP's changes (e.g., using source control), they'll have management cover right now. At each step it's important to show why it's better.

A way to do that—hard to tell if it's the right way without knowing more about the team's dynamics—is to make a lot of the changes for your own work. For example, set up your own test environment, develop there, then using this mystical "source control" magic apply the safely-tested changes to prod. Eventually someone will notice that you're not breaking prod as much as everyone else. ("You" here being either OP, or someone else in the same situation.)

All of this is just nuance, politics, and team dynamics layered on top of the excellent recommendation I'm replying to.

Hey! I know this is a bit late, but Part 1 of Basecamp's book "Shape Up" might be helpful too. It's not explicitly about specs, which is probably why I didn't think of it before, but it's worth a skim.

https://basecamp.com/shapeup/webbook

Are you talking about from the employee's point of view, or the HR process? I'll answer from the employee/team's point of view, because that's more interesting. If you're looking for the HR tools, disregard this answer!

My current company uses a Miro board for onboarding (with links to Confluence pages, Google docs, Slack channels, and other things we need).

A previous company I worked for used random links people threw at each other in Slack. Before I left, I'd put together a Google sheet (or the Microsoft cloud equivalent, now that I think about it I don't remember which platform we used there) that included set-up tasks, people to meet, things to read/understand—pretty much everything someone would need to get up to speed. The big advantage of that over Miro (or Trello/Jira/etc) is that everything was visible in one place, with due dates easy to see and to calculate based on start date, and owners easy to identify.

I'm not sure if this will be useful, but https://www.cybadger.com/2022/07/02/a-tale-of-two-onboarding... gives some details about other onboarding experiences I've had. Apologies for the shameless (well, some shame involved) self-promotion; feel free to ask for more info if it'd help!

There are a lot of different levels of rigor you can aim for when writing a spec. But at its most simple, a spec simply captures what you want the product to do in enough detail that you can later focus on implementing. The "big decisions" are already made. It can be as simple as the classic napkin sketch, a few notes on a whiteboard, or hundreds of pages of extensively-reviewed "shall" statements in binders.

But start with Joel Spolsky's classic "Painless Functional Specifications" (read the whole series) and you'll be starting in a good place.

https://www.joelonsoftware.com/2000/10/02/painless-functiona...

I'm close to your age, male, been married for quite a while, kids. So take what I write with appropriate amounts of salt, because things definitely look different at 41 than 21.

I've had some guy friends who have been similarly focused on getting married. Great guys, who for the record, are now married to lovely women. But it definitely didn't happen on their timelines or on the paths they intended.

By now you've almost certainly got your list of must-haves and dealbreakers set. But it's interesting that you've been pretty vague about the reasons that most of your relationships haven't worked out. I don't think you're being evasive. But I do think maybe you just don't know. For any given guy, you can give a yes/no answer, but maybe you can't say why.

So let me ask you about your dreams of falling in love and having a family, because there might be some clues in there. What _are_ your dreams? Are they dreams of tying a bow in the hair of your 4-year-old daughter in a princess dress? Watching your 10-year-old head off to summer science camp? Wedding day? Baby shower? Bringing the new baby home from the hospital? Volunteering at the kid's school? Arranging the perfect birthday party?

Or are they dreams about long walks on the beach with your husband? Walking down the aisle on your wedding day? Going line dancing? The two of you making dinner together and snuggling up on the couch to watch a pretentious artsy film and MST3K it? Or family camping trips? Cross-country drives to see the national parks? (Side note: if, in the previous paragraph, you didn't quite notice that none of those items involved a husband, that's worth reflecting on. Not worth getting worked up about, but worth reflecting on.)

The dreams you've had all your life might help you understand what it is that's keeping your dates from turning into more. For example, if you pictured an adventurous husband who'd teach your kids to ride horses and you realize you're dating super-placid, risk-averse dudes, that might be a light-bulb moment.

Two pieces of advice, then a bit of encouragement.

First, it seems like you're hyper-focused on getting married. Relax. Observe. Enjoy. Meet some guys with the express purpose of getting honest feedback on how you come across. In your own mind, take marriage off the table for six months to a year. Just plain not allowed. Maaaaaaybe you can date. If you've a trusted friend, she can give you permission to go on a second date if there's a guy that's just perfect.

Second, there's a surprisingly deep piece of advice hidden in the trite-sounding "become the person the person you're looking for is looking for". You need to know who/what you're looking for. To do that, you need to know yourself well enough to know who/what you're looking for, and that you're not adding extra criteria on top of that. ("He has to be kind...oh, and handsome! and rich! and famous!") It sounds like you've been working on yourself, but maybe a little bit more focused on making yourself a better catch, rather than on figuring out what you're going after and choosing the right bait (to stretch the fishing analogy too far!).

So that advice really all kind of fits together.

But now, the encouragement.

If your guy friends are telling you you're smart, beautiful, fit, kind, emotionally mature, well, I've never met you. I'll trust what they're saying. Ms. Actfrench, I agree with them. You are smart and beautiful and kind. You're working to make the world a better place. That's remarkable. If one of my daughters turned 41 and wasn't married, but was smart and beautiful and kind and working to make the world a better place, I'd tell her I was proud of her and it'd be the truth. And I'd tell her this, too, if she were anxious to get married: It's discouraging when things don't work out the way you want them to. So keep on making the world a better place. And as you're doing that, there will come a time when you'll look to your right or your left and see a guy who's also working to make the world a better place and you think he might be something special, give him a chance. Maybe he'll be the one you get to make the world a better place with, together.

(Hope this helps!)

My favorite estimation hack / joke is similar: take your best estimate, double it, and move up to the next higher time units.

So "oh, an hour or so" becomes 2 days. A week turns into two months.

I don't usually express those estimates, but it gives a good check on an initial, usually optimistic guess.

This just in: the Surface Transportation Board is requesting additional data from the Class Is for reasons that sound highly relevant to the original article. https://www.progressiverailroading.com/federal_legislation_r...

My time in rail was all related to positive train control (PTC), which is a safety overlay that stops the train before anything bad happens, at least in theory. The railroads generally despised the idea because it would slow down overall network velocity. It was only when it was mandated that they really got started with it beyond science projects.

I'm pretty far from rail these days, so I know I'm out of date. But as I recall, the prediction algorithms didn't work as well with distributed power (locomotive in the middle of the train, almost required for trains this long). So it's entirely possible that these super-long trains aren't able to predict unsafe conditions. I also vaguely recall they didn't predict anything to do with buff and draft forces (or other in-train forces) that could lead to the kind of derailments the article discussed.

This seems odd given the safety culture of railroads (every meeting I attended as a vendor, even if it was just a handful of people who had known each other for years, started with a safety briefing that included evacuation instructions and who was CPR qualified, along with tripping hazards and such). But around the time I was leaving the industry, CSX was spending lots of millions of dollars to bring the (now-late) Hunter Harrison in to implement Precision Scheduled Railroading. That led to a rush for other roads to implement it, to the point where I believe BNSF is the only Class I that does not do PSR. And PSR is all about reducing costs, cutting manpower, mothballing locomotives—which absolutely could lead to the sort of stuff this article is about. And, because it is (at least was) so fashionable in the industry, a road moving away from PSR (whether announced or just in practice) would likely see a stock price plunge and a CEO change.

Makes me wonder if, stuck between a rock and a hard place (ballast and the rail?), the roads are hoping the STB steps in and makes a rule to stop their game of chicken.

I agree 100%, based on my own experience both as having been a kid and being a parent.

Like a lot of other folks have already posted, I was also the weird sort of kid that spent time "playing on the computer" and talking about what I'd learned and asking about "modems" and "BBSs" or "the Internet". My parents would listen, supported getting an extra phone line to run my own BBS, would drive me places to support my hardware and books habits--and that all was important to continuing to explore this niche.

As a parent, well, I have an interesting mirror experience. My oldest daughter got really into basketball. This is absolutely inexplicable to me, because neither I nor my wife ever played, nor did we ever watch a basketball game at home before her interest developed. (Schools these days, exposing children to strange new ideas!) I knew the basics (orange sphere through orange ring = points; double dribbling and traveling are bad; no tackling) but really had no interest. But we've enabled her interest: let her join the school team, signed her up for summer camps or 3-on-3 leagues, encouraged her to practice in the driveway (oh, yeah, bought a hoop for the driveway), have watched or taken her to college women's games.

She still knows more about the game than I do. Even with years of watching, "volunteering" for scorebook duty at some of her home games, talking with coaches and refs, there are still a lot of subtleties of the game that escape me. But it's okay. She plays, she enjoys it, and she knows her parents support her strange, strange interest.

Even if you don't really, completely "get it" as a parent, supporting and enabling ("enabler" is such a good word here) is worth a lot.

I used to ride my bicycle to work most days. I like to ride. I am all for "a bicycle is a vehicle", but I still think this adjustment makes sense.

Being able to treat a stoplight like a stop sign is great. It's pretty common for stoplight sensors to not detect bicycles. It's also common for polite folks in cars to stop far enough behind a bicycle that their cars don't get sensed. It's not a good feeling to sit on the sensor loop, watching the walk lights cycle and reset, knowing that if you don't run a red or walk out of the intersection, you'll be stuck.

As for treating a stop sign like a yield sign, I agree with a lot of other posters who come citing sources: bicycles move slower and are at a lot of risk from cars coming up from behind. It's not about the extra effort to get started (though in a hilly place, I could see that being a problem for some riders).

As a cyclist, bike safety is hard. You're squishable and very aware of it, surrounded by big, fast, solid cars whose drivers often aren't paying close attention.

As a driver, bike safety is hard. A lot of drivers get weird around bikes (e.g., they yield the right-of-way when they shouldn't). Cyclists often aren't well-trained in the rules of the road. And the rules of the road often force bikes and cars to intersect in ways that aren't ideal.

So I think making it clear that yes, bikes are vehicles, but making a few exceptions to improve safety by reducing the chance of bicycles getting unintentionally hit from behind--seems like a win to me!

Hey Adam, it's pretty fun! I agree with some of the other posters that landmarks and businesses could be a good addition.

I did have some trouble understanding how it's calculating distance and drawing the dashed line. It does not always draw the shortest distance from the pin to the polyline for the road. I tried a few rounds with some deliberately wrong guesses and I'm still not sure I know what it's doing. Some examples:

(1) A road that runs from southwest to northeast. I placed the pin to the southeast of the road. Eyeballing it, the shortest distance is roughly northeast. The dashed line was drawn 10-15 degrees east of north. If it's significant, it drew to an intersection (not the nearest, but reasonably close).

(2) A road that runs east-west. I placed the pin north of the road by 50-60 meters. The dashed line was drawn 15-30 degrees west of south. It did not draw to an intersection or other point of interest. It may be drawing a ray from the center of the circle of interest.

(3) A road that runs north-south. I placed the pin east of the road by 40-ish meters, near the north edge of the circle. The dashed line was drawn 15-30 degrees west of south (my guess in #2 about a ray from the center was wrong), to an intersection, giving a 102 meter distance.

(4) A discontinuous street. (Replicated for a different street! 4th St and 5th St in Marion, IA, if it helps.) The street runs north-south but has a quarter-ish-mile gap. I placed the pin not far from the southern section of the street. The dashed line was drawn from the pin, past (and nearly parallel to) the southern section, then connected to the southern tip of the northern section. Interestingly enough, the distance looked like it was pin-to-southern-section.

(5) A north-south road in rural Iowa taking advantage of the 1-mile grid. I placed the pin near the center of the circle, slightly less than one mile from the nearest point of the road. It drew the dashed line northwest and showed a distance of 2002 meters. I would have expected due west, and ~1500 meters.

(6) A road that runs north-south (with a bit of southeast a half mile south of the circle), that happened to just barely peek inside the circle on the far west. I placed the pin near the outer edge of the circle, roughly northwest. It drew the dashed line nearly due south (several miles!) but reported a distance of 281 meters.

Sometimes the distances seem reasonable even if the dashed line is drawn to a different point on the road. Sometimes the distances and the dashed lines both seem to be off. Intersections seem to have something to do with it, but there also seems to be something else going on too.

For testing, if you're interested, the intersection of "White Road" and "North Alburnett Road" in Iowa (between Marion and Alburnett) is great. It's sparse, gives you nice straight roads, with just a few driveways and other points-on-polyline to confuse(?) algorithms. If you get C Ave Extension just barely in the circle on the west, that's #6.

And for what it's worth, I had fun trying to figure this out!

There were two things that helped me overcome perfectionism. Well, probably more, but two that stand out.

One was getting focused on the purpose of my activity. I'm writing a letter to persuade X of Y. I'm writing documentation so users know how to do Z. I'm coding a module so the system can do W, which lets users do A and B. I'm patching this drywall so my house looks nicer. Then I can subvert whatever perfectionistic impulse comes my way. Maybe what I can do in the time I have, with the knowledge and skills I have isn't perfect, but it's better than what exists now. Maybe I can't write a full manual with screenshots, but I can at least create a Help page with a few bullet points--it's now better than it was, and that is progress toward achieving the purpose I set out after.

The other was having fun. Not necessarily at work or other tasks (I do have a friend that loves doing drywall; I do not feel the same!). But I found the more fun I had in life, the less hold perfectionism had on me. If I go throw a frisbee around with a friend, it doesn't matter if not every throw is perfect. It can be kind of fun to try goofy shots on a basketball court. What if I try playing a board game with a completely different strategy than usual? I might learn something, my friends or family might tease me, I might lose. Oh well. What if I try telling jokes and they fall flat? It wouldn't be the first time! Just having fun and enjoying the moment seems to keep me from focusing on myself, and that's a big part of it.

Come to think of it, being a parent (especially of small kids, because nothing is perfect in a house with small kids--wait, and older kids, because there's no way to keep older kids thinking you're perfect) helps too. And managing people (at work, or coaching a team, or coordinating volunteers), because in the practice of tolerating imperfections in others, I learned to tolerate them in myself, too.

And as I skim this over before posting, I realize that a lot of it is being less focused on myself. Easy to say. Tougher to do. And almost impossible to do when trying it.

As a framework, I've yet to find something better than the Manager Tools "Trinity" which includes coaching [0].

The short version: work with each of your directs to have a coaching goal. Help them define one or more next steps. Then let them get after it, with you holding them accountable for the steps that you defined together. You can do effective coaching in ~5 minutes per week per direct. That's not just what the Manager Tools podcast says; I've done it.

Just have one coaching goal at a time. It should be something that is pretty apparent if they've achieved it. "Get better at $COOL_TECH" is a lousy goal; "learn enough COBOL to be allowed to take $LEGACY_APP pager duty" is a nicely-measurable goal (if lousy for other reasons).

Steps will be small. You'll start by brainstorming resources with your direct. Then it might be tiny steps like "email me to confirm you bought $BOOK from Amazon by end of day today", "send me a note on Slack with the date of your meeting with Bob about $TOPIC; complete scheduling no later than noon Friday", "show me your 'Hello World' program by end of day Tuesday." Small steps early help keep the coaching work in-mind for your directs. Reporting steps to you helps them avoid putting tasks aside for a week, then scrambling to catch back up. That slows the coaching project down and stresses them out.

One of the biggest stress-relievers of the model is that "coaching" isn't the same as "teaching". Coaching resources can be books, courses, other people in the company, etc. It's also not (necessarily) related to the projects your direct is working on. Providing projects where they can stretch and grow is great (keep that up!), but there might be other skills they need to learn. Running meetings, sales, design, interviewing customers, working with other departments... Your company has its own set of skills. And it's okay if they want to learn something unrelated. A while back, I felt like I needed to learn to draw better, and I had a great boss that agreed that was worth learning on the job, even though I am not and never will be a designer-type. YMMV based on your organization, of course.

How many direct reports do you have? Having too many can make things a lot more difficult, not just for coaching.

This was a bit quick, but if you have questions I'd be happy to help!

[0] https://www.manager-tools.com/2009/07/coaching-model-revised

I second the recommendation for Manager Tools. Start with the "Basics" casts on one-on-ones, feedback, coaching, and delegation to get up to speed. Their book The Effective Manager by Mark Horstman is a great place to start, too.

The podcast was super helpful to me in transitioning from IC to management.