Soft Skills Engineering - Episode 301: I forced the framework and product stealing credit

Episode Date: April 25, 2022

In this episode, Dave and Jamison answer these questions: Listener Casey asks, My team has built an internal framework for continuous delivery that enabled a key product release last year. The tooling has gained widespread adoption and popularity throughout the org, to the point that some leaders are requiring teams to use the framework for any new services. Things are generally going great, except that “my team” consists of only 2 people including myself, and we have so much work that the soonest we can look at new features is ~18 months from now. Some individuals, who are being required to use our framework, are frustrated and protesting loudly about how the framework doesn’t work exactly the way they think it should. How can I shelter my team from the outbursts of unhappy users? Or bolster their resolve so they don’t take on the anxiety of growing pains? P.S. We’re all remote so this happens 99% in chat channels and DMs. If something goes right, product takes credit. If something goes wrong, engineering takes the blame. How do you change that organizational dynamic? (Other than your usual answer.)

it takes more than building a framework that nobody uses to be a great engineer this is soft skills engineering episode 301 i'm your host dave smith i am your host jamison dance soft skills engineering is a weekly advice podcast for software engineers about all the non-technical stuff like why is nobody using this amazing web framework i created you're not investing enough in marketing you don't have enough stickers for it yeah you need a conference first yeah i wonder what would happen if someone just went all in on building their internal kind of company only framework but put all the marketing polish on it commissioned a logo made stickers made t-shirts asked for sponsorship actually that's kind of like a real thing i guess

wouldn't it be crazy if people got paid to write open source code how how wild would that be this episode is sponsored by revelo which is a great way to hire engineers for your team you can go to revelo.com soft skills to hear more or just listen to the episode that you can all right shall i thank our patrons please okay we have a bunch of people here to say thank you too they are craig motlin rum and code i love mavis the stochastic parrot alice jost or jost i'm sorry alice andrew pollock the geek your job podcast ian walter arunduna patron.com.au we're hiring ira chan monkey face emoji jonathan king testing is documenting.org oladapo fadayi rm rf prod ragnar hardison timmy garabrant nick hathaway travis anders brayden canes john grant nick

cantar and philip john basile if you would like to join this illustrious crew and have your name emoji or unpronounceable word in any language including klingon said on this podcast all you have to do is go to softskills.audio and click the support us on patreon button and give us a sizable amount of money that will make a material impact to jameson's retirement age like by decreasing it is that what you mean yes by decreasing your age your retirement age i will give enough money to jameson that he will spend it foolishly and and ruin his life thus increasing his retirement age that's the goal perfect okay should i read our first question go for it this is from a listener named casey who asks my team has built an internal framework for continuous

delivery that enabled a key product release last year the tooling has gained widespread adoption and popularity throughout the org to the point that some leaders are requiring teams to use the framework for any new services things are generally going great except that my air quotes team consists of only two people and we have so much work that the soonest we can look at new features is about 18 months from now some individuals who are being required to use our framework are frustrated and protesting loudly about how their framework doesn't work exactly the way they think it should how can i shelter my team from the outbursts of unhappy users or bolster their resolve so they don't take on the anxiety of growing pains

P.S. We are all remote. So this happens 99% in chat channels and DMS. Wow Congrats on building something people actually use Yeah, you've gotten through the first problem that no one uses it now to the second problem, which is as soon as you have users They want stuff Yeah, exactly this says in chat channels and DMS, i'm just going to go ahead and assume that the DMS are on instagram and You use slack for your public chat, but use instagram dms to keep things private Yeah

Part of your onboarding is you have to follow the ceo on instagram, right? So you can dm each other Yep, I don't know if that's I don't know. Is that how it works? I'll never know So part of why I picked this one is because this is the inverse of a question from last week about The the people being forced to use the thing, right? You are the the cause of this problem kind of indirectly. Yes I mean, can you just do the like rtfm? type thing of saying patch is welcome yeah like do you have an open source culture in your inside

your company that's a good way of telling someone to buzz off without saying those words sometimes right we have an open source culture pr is welcome yeah and buzz off it's a ton of work to manage open source contributions so if that actually turns into someone saying great i will do it then you've taken on a lot of extra work yeah so i guess you kind of hope they say no although good news you're actually getting paid for this one so it's a little different yeah that's true you get paid for the work how novel some leaders are requiring teams to use the framework why do you think they're requiring it do you have like why would leaders do a thing such as this i mean it must it must be filling a gap that many teams have and be really valuable but you know surely it

couldn't be the kickbacks that you're giving those leaders to recommend your internal project to them yes boy that really backfired yeah oh no and now we owe someone timeshare tickets so that's what it means to get paid for doing open source in your company that's that's called paying for advocacy yes recognizing that it's a valuable role that deserves compensation yeah i mean this is tough you've created a successful thing and now you're going to pay the ultimate price for successful things, which is it's going to take over your life. Or you're going to ignore it and do your job. Because here's what I'm guessing. This team actually has software that they are responsible for delivering that has nothing to

do with this continuous delivery framework that they happen to build. And so essentially, this is a resourcing problem. You have a company that has stumbled upon creating a really valuable tool but they never resourced it probably never even intended for it to be built and now it's just like silently unowned i think or maybe vocally unowned yeah it's interesting you assume that i assume that they had 18 months of like maintenance work to do which sounds less likely after i say it like yeah on this open on this internal framework yeah kind of seems like that i think that lends even more weight to your patches welcome comment like will you do all the stuff for me that i will not get to if i add these features for you i mean one thing you need to do

or can do is raise the shared like resource contention up because someone's job somewhere is to help decide between competing priorities and how much you invest in them and so the teams themselves have their own incentives within the team but theoretically there's someone who could say well we have these five engineers doing thing x and two engineers doing framework thing y but it really would be more valuable for the company overall if we moved to from thing x to thing y or get it recognized that like too bad the stuff that they're doing already is more valuable than the features that you want added to this framework right but at least you can get an answer and you won't if you don't say hey we want we want we want to do this thing or we want someone else to do

this thing and there aren't people to do it right now yeah i think you nailed it on the head i think casey the listener here says or is asking this question because they don't have like direct authority to make these kinds of resource allocation decisions which tells me they're probably not in management yeah it's like this is a manager's job is to identify priorities for the team and company and allocate resources to those priorities according to their wishes and you are now you're either not in that role or you have allocated in such a way that you now have pain you know let's assume that oh no what i've sewed it's back i'm reaping to reap it i mean let's i'm just going to assume with this next comment that casey is not in a position to

directly control how many engineers or how much engineering bandwidth is allocated to different things like this framework i'm going to say look you have an opportunity to do something that i've seen done at big companies, which is called community ownership. And the way community ownership works is, first of all, you kind of set up a webpage internally for this project so that people know this is a thing. And then you ask for volunteers to own it. And community ownership can be very challenging, but it can also work very, very well. I sense this is a pretty big company. It's probably not just like four other people at the company. This is probably, i'm guessing dozens of engineers and so community ownership the idea is you you make a case for

teams to give up a fraction of their engineering capacity to support this tool that benefits everyone and if you can do this successfully it's actually super great because you distribute ownership among lots of different people so a lot of people now know how it works and can keep it alive in the event that one team is decommissioned or someone leaves it can also fail drastically, very catastrophically, wherein it's the, what is it called, Jameson? Tragedy of the commons, where it's owned by everyone, therefore no one takes care of it. What's the harm this one little go-to would add? I just really need this feature real quick. Exactly, exactly. But when I worked at Amazon, there was a lot of community-owned projects,

and they happened just like this. Someone found a new way of doing things. It got successful, it got adoption, and so then it became a community-owned project, and teams just kind of graciously offered to let a portion of their engineering bandwidth be dedicated to helping it work. And it worked at Amazon because the culture there, one of the leadership principles there is ownership. And a big part of ownership is being willing to help the company succeed, even if it means your team's short-term success might not be as readily, it might not happen as readily as it would if you didn't. So anyway, I would go for the community. In this situation, I'd probably go for the community ownership model, but it's going to require you to be a pretty excellent marketer

and kind of an internal evangelist. Now, was there someone who was trying to arrange or organize the contributions of others, or was it purely engineering-driven where people worked on it and they just kind of did what was needed with what they thought? Does that make sense? I actually, I don't know. I never got so involved in a community-owned project. I was just the beneficiary of them so i basically took advantage of the tragedy of the commons and yeah exactly the awesomeness of the common right the awesomeness for me oh sweet free commons right oh man did you know you could just throw your trash in this park and someone else will pick it up it's so cool i got the sense that it was kind of like an open source project how there were like

folks who were in charge of it maintainers if you will and they kind of formed committees of or chair you know what's the word I don't even know I never got that close to it but I could sense that there was a structure you know there were names on wiki pages and things that made me think okay there was like a group of five people who are more or less in charge here yeah well that doesn't sound like doing less work for this team it's just well yeah it just sounds like getting more help so I went from skeptical to make sense within a sentence that's nice it's amazing how you can trick your brain into changing its mind by by forcing your brain to say what it's thinking how can i shelter my team from the outbursts of unhappy users

oh yeah that's a good question i don't think you can if you work with the users and they're unhappy with the i don't know make something perfect i yeah i don't think you i think i don't think you can, especially with like two people. I mean, you could say there's someone who manages the feedback and sanitizes it, but... But it has to be one of those two people probably. Yeah, exactly. So you can, your team can, half of your team can protect the other half of your team. I mean, I would, if you want to protect people, a really good way to do that is to write a document that's visible to everyone in your company, who anytime they, your team members get a complaint, they can just link them that document. And the document explains, look, we built this.

We are not actively maintaining it right now. It needs an owner. How about you volunteer? You know, rather than just forcing them to kind of be that poor person sitting in a customer service cubicle farm answering irate phone calls. Yeah. I'm sorry. Your bugs are very important to us. We will be with you in 18 months. You can request a callback in 18 months. yeah i like that i mean who among us has not raged at internal tools or external tools that have been forced upon them it's kind of like a natural reaction that's fair but it's fair if if you can engage the humanity in these people by saying like look i'm a person at this company trying to solve a problem and i built this which i think is part of what part of what your solution

would achieve of kind of linking people to stuff it could change their expectations a little bit from someone must provide the perfect tool with someone being this vague nebulous abstraction to, oh, like this person who has a million other things to do built this thing that's kind of helpful. And the gap between it and perfection is something that I can do something about

as a person at this company or not. I mean, maybe you wrote it in something very obscure. Yeah, it's like this was the- You've cursed yourself. Yes, exactly. It's actually a language we invented. Ah, to go faster. Yes.

That's right. Maybe that's why it takes 18 months to do anything on it. We first have to rewrite it in a language everyone knows. First, we have to add support for functions to our language. Very nice. Have we answered the question? I think so. Good luck.

It's a tricky thing. You're now a victim of your own success. Congratulations, and I'm sorry. Someday, I hope to be there. Hey, Jameson, have you heard how easy it is to hire engineers right now? Given infinite dollars, it is easy to hire engineers right now. I just don't have those. Yeah, it's tough.

I want to recommend a company that helps you hire engineers in Latin America. It's called Ravello. Tell me about it. I've been hiring engineers in Latin America for the past two years, and they are awesome. I've worked with a few different companies who provide engineers from Latin America, but none of them were really great. I recently discovered Ravello. Ravello helps you find skilled software engineers in Latin America. They only provide full-time senior engineers with at least five years of experience. They don't force

you to pay for things you don't need, like a project manager. This is really interesting. Their pricing is awesome because they charge a monthly fee and you know how much they're paying the developers. So there's not a lot of indirection there, which is not common. Sometimes you get these opaque invoices and you have to figure out how much is actually going to the developer, how much is going to the company. They do the sourcing and the vetting, and you can interview the engineers before deciding if you want to work with them, and they take care of payroll and benefits, which is great. Yeah, I highly recommend hiring engineers in Latin America. It's a huge untapped market for a lot of U.S. companies. All of Ravello's engineers speak English,

and the time zone is one of the big wins. If you're based in the United States, the Latin American time zones line up really well with U.S. time zones. You don't have that painful 24-hour turnaround problem when you have a question for an engineer on the other side of the world yeah i worked with wonderful engineers that live on the other side of the world and both of our lives were worse because someone's always up at midnight so this is great check out ravello today you can go to ravello.com soft skills to check it out that's r-e-v-e-l-o.com soft skills all right do you want to read our second question dave yes this comes from an anonymous listener who says if something goes right product takes credit if something goes

wrong engineering takes the blame how do you change that organizational dynamic other than your usual answer which is what how dare you assume usual answer keep your job yes surely that's what you mean i have a couple thoughts about this one all right the first thought is i wonder if you asked product about the dynamic would they say the opposite something goes right engineering takes credit if something goes wrong product takes blame like is this is the perception thing and maybe is the answer i don't know what you do about it it'd just be interesting to know yeah i forgot my other thought was that was going to be the really good one i think yeah it was going to be so good i felt it sparking in my brain and it's lost dang well we'll just

wait in silence yeah here's what'll happen i'm gonna start making a stupid comment guaranteed three words into this thing it's coming right back to you okay go okay so here nothing nothing i have nothing okay well then i'll make a real comment i'm thinking okay i'm thinking when you have a situation where product takes credit engineering takes blame oh man i'm resisting the urge to say well that's just a symptom of a deeper problem why don't you go figure out the deeper problem and come back to us when you've got that understood but it's a classic consultant slash coach move yes but i i think that what when i've seen i mean here's the thing when something goes wrong it usually is engineering's fault i mean yeah you there are times when product

designs the wrong thing and then engineering builds the wrong thing and then engineering gets the blame but a lot of times it's like oh yeah bug the product team will say like i didn't tell you to write a bug you know it's like so okay that's engineers fault all right fine and then when you launch new stuff and it works like the product department is usually set up very well with all of their mechanisms and rituals to share congratulations like it's like what they do you know in fact probably i don't know 70 of a product manager's job is communicating all this stuff and so they've already got all the communication channels to say when good things happen and they've got the ears of the whole company so it kind of is natural for the product team to

always be celebrating and the engineering team to always be fixing problems you know so so like i guess i'm just saying that this is this is very easy for this to fall into and i think aside you know the the best way to solve this problem i think is to have people in the product organization who are credit sharers meaning that when something really great happens with your product you built some awesome feature it gets a ton of adoption it makes users happy they are the first to say i'm so glad i partnered with the engineering team to so and so and so and so and here you know here are five names of people who contributed to this you know that's the best way but you know given that this product team isn't really doing that already it's hard to just tell them to start doing

it but maybe that's the answer they say look why don't you start saying the names of the people who contributed to this when you celebrate it and maybe they'd be like oh yeah i should do that Hmm. It's also, I found that celebrating others' accomplishments by example can help kickstart that a little bit. So you can start doing it. And the good thing is most reasonable people will like that. And if you're being cynical and like political, you win the status game by doing that. You demonstrate power by your ability to dole out recognition to other people. like it's not a position of weakness i guess that's what i'm saying i don't think it would hurt you even if no one else took it up to be known as a person who shares credit with other people yeah for sure a thing i like to do whenever i do something wrong and someone talks to me about it is say i prefer more of a blameless culture and i don't think we're gonna gonna achieve that if you tell me that i did this thing if you give me negative feedback i don't see how we can have

a blameless culture i'm gonna need you to tone it down a little bit stop talking so negatively about the horrible bugs that i introduced something goes wrong engineering takes the blame yeah there's there's a balance between like figuring out what happened and and what to do differently and blaming and when stuff goes wrong it makes sense to try to figure out why it went wrong and what to do differently but it's so easy to step over the line into like stuff went wrong because engineering screwed up and and like someone needs to suffer for this and they they will bear the burden of having done it wrong and that's that's part of the goal of these of this this just culture blameless culture thing is is it's really hard to learn from things that go

wrong if your incentive is to protect yourself not find out what happened the end of this road of blaming engineering is engineering becomes very defensive yeah and like estimates become huge because they have to protect themselves against against they can't do anything wrong right because the that's right they've got to reduce risk to a minimum yeah because the consequences of errors are so high yeah which i'm sure you know as a person who posted this question yeah i mean i i would figure out in what forums is product taking credit for all the good things you know is there a meeting where the company all gets together and they celebrate these things are there blog posts that go out are there emails that are being shared you know slack messages

what is it figure out that forum that they're using and then go talk to the people who facilitate the messages in that forum and just ask them to credit the engineering contributors every time they do one of those things. They'll probably say yes. I'm sure these people, well, okay. It's possible these people are pure evil, but unlikely. Most of the time, people, I think, when you say, hey, I'd like you to share the credit with others, they're excited and happy to do so now that they know who to share it with. So I would suggest find those forums, insert the names so that everyone gets credit and then just kind of make sure that that happens and i think you'll probably see that the culture will shift pretty quickly yeah i mean one tricky part

about this is it's way easier to advocate for other people to get credit than to advocate for yourself to get to get credit um so you need an ally you you have each other's backs right you partner with another engineer and you you ask each other to provide cover yeah listen listen bob i shipped some really great code on this feature that product's going to announce will you go tell product that i did that thanks bob in a perfect world this is something your manager would be good at is is understanding people's contributions and making sure they get credit there's a lot of stuff that should happen in a perfect world that might not so maybe this will not happen dave i think you've got a great solution for the takes the credit side but what about the takes the blame

side yeah i i don't know i i tend to like i tend to take blame on myself i don't really feel an urge to spread it around you know yeah so use it to make yourselves make yourself stronger right i just yes i like it's like lifting weights yeah for my mind wait i thought that was sudoku That and taking all the blame. It's heavy. You and I have talked before about how you can fail well, right? And so I think learning how to take blame in such a way that is super productive is actually a really valuable skill to have, you know, where you say, okay, everyone, I'm going to get out ahead of this. Here's exactly what happened. Here are all the things that took place in engineering that led up to this problem.

And here are the things we're putting in place to make sure that this doesn't happen again. and you share that every time there's a you know some kind of fault to be had uh you proactively share that and i think people really really appreciate that i know they do they tell me that all the time about my own team nice no one ever tells me that about my team and i think that's because we just never fail so there's never any blame to go around that's a good point that is that is the no bugs driven development approach that we all should espouse that is the higher the higher uh level of skill at this yes i imagine there could be a a contentious relationship between product and engineering if this is a dynamic that's happening if you can get

a reasonable ally in product that that um wants to do better not uh like dole out punishment and reward that will help as well like if product is being defensive about blame and trying to pin it on engineering that's a rough situation to get out of but if you can have someone on your side who doesn't think that's an awesome approach they can sort of influence within product a bit easier than you can say no uh when they say you you wrote this bug or whatever yeah i mean what you want to do is like get away from a place where product is looking around for or anyone is looking around for like who can who can i blame for this right and if if you have a better relationship you the royal you if engineering and product are closer then then i think they're more likely to see this

as a shared problem yeah undoubtedly but you probably got some culture shifting ahead of you that's my guess yeah it is easier to do no bugs driven development than to shift a culture like It's easier to just not screw up. So you could try that too. Give it a shot. Most people say they like it. And if you don't like it, it's very easy to switch back. Well, no, if you don't like it, you have done it wrong.

And you need our consulting help. Yes, you need our extremely high rate consulting. Yeah. All right. With that, have we answered the question? I think so. Good luck. Yeah, good luck.

What should people do if they want their own questions answered? go to softskills.audio and click the ask a question button you can fill out our form there and as usual we have to say thank you so much to everyone who does this we get a lot of wonderful questions every week we love them we love you keep them coming thank you so much we'll catch you next week