-
Notifications
You must be signed in to change notification settings - Fork 0
/
listen-instead-of-getting-buy-in.html
67 lines (56 loc) · 4.91 KB
/
listen-instead-of-getting-buy-in.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
<!DOCTYPE html>
<html lang="en">
<head>
<title></title>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<meta id="keywords" name="keywords" content="">
<link id="stylesheet" rel="stylesheet" type="text/css" href="https://oskipa.github.io/theme/css/code.css"></link>
<link id="stylesheet" rel="stylesheet" type="text/css" href="https://oskipa.github.io/theme/css/site.css"></link>
</head>
<body>
<header class="header">
<h1 class="site-name">
<a class="home-link" href="https://oskipa.github.io">Dada</a><br />
|> Structures<br />
|> Algorithms</h1>
<nav>
<menu class="minimal-menu">
<li><a href="https://oskipa.github.io/pages/today-i-learned.html">til</a></li>
<li><a href="https://oskipa.github.io/pages/now.html">now</a></li>
<li><a href="https://oskipa.github.io/short_index.html">index</a></li>
<!--
<li><a href="category/log.html">web log<a></li>
<li><a href="">about<a></li>
<li><a href="">site map<a></li>
-->
</menu>
</nav>
</header>
<div class="container">
<div class="row">
<div class="col-md-8">
<h2>Listen instead of getting buy in</h2>
<h3></h3>
<label>06 May, 2020</label>
<p>I learned recently that product owners and managers are trained to seek team members to buy-in into new process, goals, or plans. This was an unfortunate word selection. It undermines building trust in a team. It frames the relationship between managers and workers the wrong way.</p>
<p>"Buy-in" sets a narrative where the manager wants something that the workers are resistant to do. The goal of the manager becomes getting that buy-in, that verbal agreement. The manager becomes a high pressure salesman. Workers are reluctant customers. A successful manager, like a high pressure salesman,is meant to make that sale, no matter what. In high pressure sales, you will ignore objections. All you want is an explicit or implicit yes, even if it is not real. </p>
<p>A better approach is to listen. Everyone wants to succeed. As a manager you may have a vision to implement, either personal or given by your supervisors. Your workers know the obstacles that are in the way to get that done.</p>
<p>Let me give you an example. Upper management learned about threaded programming. They want the project to use threaded programming. It should make response time faster. Fair enough. You go to your team and you announce this. The team tells you that it is not a good idea because the legacy project is using Ruby, and Ruby's thread model is not robust.</p>
<p>If the manager has a buy-in mentality, they will think that the workers are stuck in their ways. That they don't want to adapt to new ideas. The manager's task now is somehow to win them over and agree to do the task that must be done. It sets an adversarial relation with the works. It is easy to ignore what the workers are telling you because you need that win. The manager does some googling and finds that there are threads in Ruby. The devs must be ignorant and are too prideful to accept that. When an unrelated PR comes, he asks for the solution to be using threads. </p>
<p>Let's switch the frame where the manager listens respectfully. Rather than ignore what the engineers are saying, he listens. There are risks ahead. Now the manager can ask, "executives want a threaded application. How can we achieve that, then?" Then the engineers can discuss possible solutions and alternatives. Maybe what they want is concurrency, not necessarily threads. Threads is a way of gaining concurrency. If the goal is concurrency perhaps using a job framework like sidekiq is adequate. Or maybe they can try to use the new concurrency features of a future Ruby version. </p>
<p>In both scenarios there is a concurrency implementation. One of them was better planned out, and the team members felt respect and appreciated. The other one was ad hoc, and people are resentful for being ignored and manipulated. One sets up the team for future success. The other one can lead to a fragile product. </p>
<p>We all work in some sort of team. In which one would you like to be a worker in? Create that team then. </p>
</div>
</div>
</div>
<footer class="footer">
<!-- <p class="about"><a href="http://hugoestr.github.io/blog/manifesto.html">About</a> --> <a href="https://oskipa.github.io/pages/about.html" >I am</a> a software developer. I code in Python, Ruby, Lisp, and many other languages. I like poetry, museums, and ukuleles. I try to guide my life on principles of dadaism and nonviolence.</p>
<p>
<a href="feeds/all.atom.xml">atom</a>
<!-- <a href="http://github.com/oskipa/">github</a> -->
</p>
<p>Artisanally built with <a href="https://blog.getpelican.com/">Pelican</a>. Content handcrafted in <a href="https://www.vim.org/" >Vim</a>. All hallucinations are human. 100% AI Free.</p>
</footer>
</body>
</html>