cybadger's comments

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:  [email protected]

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 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:  [email protected]

I’m a full-stack developer with a preference for backend. Over the past 20+ years, I’ve worked in everything from avionics to WordPress to heavy GIS data processing. I love solving complex problems (make them as simple as possible, but no simpler), designing for scalability and sustainability, and mentoring engineers.

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:  [email protected]
  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:  [email protected]
  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:  [email protected]

###

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:  [email protected]

I’m a full-stack developer with a preference for backend. Over the past 20+ years, I’ve worked in everything from avionics to WordPress to heavy GIS data processing. I love solving complex problems (make them as simple as possible, but no simpler), designing for scalability and sustainability, and mentoring engineers.

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.