├── .gitignore ├── Humor-Sans.ttf ├── LICENSE ├── README.md ├── images ├── .DS_Store ├── 1_lcRm2muyWDct3FW2drmptA.png ├── AmazonS3.png ├── azure-storage-blob-logo.png ├── feather.css ├── peters.png └── techdebt.png ├── makebook.sh ├── plots.ipynb └── text ├── agile.md ├── alignment.md ├── askingforinformation.md ├── compensation.md ├── culture.md ├── deadlines.md ├── decisions.md ├── effort.md ├── feedback.md ├── hiring.md ├── hours.md ├── integration.md ├── iterating.md ├── juniors.md ├── managingmanagers.md ├── meetings.md ├── methodologies.md ├── occam.md ├── peoplevstech.md ├── preface.md ├── qa.md ├── remote.md ├── research.md ├── scale.md ├── techdebt.md ├── technologies.md ├── time.md ├── title.txt ├── toc.md ├── tracker.md ├── whatmakesagoodmanager.md └── yourmanager.md /.gitignore: -------------------------------------------------------------------------------- 1 | book.epub 2 | -------------------------------------------------------------------------------- /Humor-Sans.ttf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/Humor-Sans.ttf -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2019 Ron Reiter 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # managing-software-developers 2 | Managing Software Developers - An e-book on how to manage engineering teams 3 | -------------------------------------------------------------------------------- /images/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/images/.DS_Store -------------------------------------------------------------------------------- /images/1_lcRm2muyWDct3FW2drmptA.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/images/1_lcRm2muyWDct3FW2drmptA.png -------------------------------------------------------------------------------- /images/AmazonS3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/images/AmazonS3.png -------------------------------------------------------------------------------- /images/azure-storage-blob-logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/images/azure-storage-blob-logo.png -------------------------------------------------------------------------------- /images/feather.css: -------------------------------------------------------------------------------- 1 | 2 | @font-face {font-family: "feather"; 3 | src: url('//at.alicdn.com/t/font_o5hd5vvqpoqiwwmi.eot?t=1501828829848'); /* IE9*/ 4 | src: url('//at.alicdn.com/t/font_o5hd5vvqpoqiwwmi.eot?t=1501828829848#iefix') format('embedded-opentype'), /* IE6-IE8 */ 5 | url('//at.alicdn.com/t/font_o5hd5vvqpoqiwwmi.woff?t=1501828829848') format('woff'), /* chrome, firefox */ 6 | url('//at.alicdn.com/t/font_o5hd5vvqpoqiwwmi.ttf?t=1501828829848') format('truetype'), /* chrome, firefox, opera, Safari, Android, iOS 4.2+*/ 7 | url('//at.alicdn.com/t/font_o5hd5vvqpoqiwwmi.svg?t=1501828829848#feather') format('svg'); /* iOS 4.1- */ 8 | } 9 | 10 | .feather { 11 | font-family:"feather" !important; 12 | font-size:16px; 13 | font-style:normal; 14 | -webkit-font-smoothing: antialiased; 15 | -moz-osx-font-smoothing: grayscale; 16 | } 17 | 18 | .icon-alert-octagon:before { content: "\e81b"; } 19 | 20 | .icon-alert-circle:before { content: "\e81c"; } 21 | 22 | .icon-activity:before { content: "\e81d"; } 23 | 24 | .icon-alert-triangle:before { content: "\e81e"; } 25 | 26 | .icon-align-center:before { content: "\e81f"; } 27 | 28 | .icon-airplay:before { content: "\e820"; } 29 | 30 | .icon-align-justify:before { content: "\e821"; } 31 | 32 | .icon-align-left:before { content: "\e822"; } 33 | 34 | .icon-align-right:before { content: "\e823"; } 35 | 36 | .icon-arrow-down-left:before { content: "\e824"; } 37 | 38 | .icon-arrow-down-right:before { content: "\e825"; } 39 | 40 | .icon-anchor:before { content: "\e826"; } 41 | 42 | .icon-aperture:before { content: "\e827"; } 43 | 44 | .icon-arrow-left:before { content: "\e828"; } 45 | 46 | .icon-arrow-right:before { content: "\e829"; } 47 | 48 | .icon-arrow-down:before { content: "\e82a"; } 49 | 50 | .icon-arrow-up-left:before { content: "\e82b"; } 51 | 52 | .icon-arrow-up-right:before { content: "\e82c"; } 53 | 54 | .icon-arrow-up:before { content: "\e82d"; } 55 | 56 | .icon-award:before { content: "\e82e"; } 57 | 58 | .icon-bar-chart:before { content: "\e82f"; } 59 | 60 | .icon-at-sign:before { content: "\e830"; } 61 | 62 | .icon-bar-chart-:before { content: "\e831"; } 63 | 64 | .icon-battery-charging:before { content: "\e832"; } 65 | 66 | .icon-bell-off:before { content: "\e833"; } 67 | 68 | .icon-battery:before { content: "\e834"; } 69 | 70 | .icon-bluetooth:before { content: "\e835"; } 71 | 72 | .icon-bell:before { content: "\e836"; } 73 | 74 | .icon-book:before { content: "\e837"; } 75 | 76 | .icon-briefcase:before { content: "\e838"; } 77 | 78 | .icon-camera-off:before { content: "\e839"; } 79 | 80 | .icon-calendar:before { content: "\e83a"; } 81 | 82 | .icon-bookmark:before { content: "\e83b"; } 83 | 84 | .icon-box:before { content: "\e83c"; } 85 | 86 | .icon-camera:before { content: "\e83d"; } 87 | 88 | .icon-check-circle:before { content: "\e83e"; } 89 | 90 | .icon-check:before { content: "\e83f"; } 91 | 92 | .icon-check-square:before { content: "\e840"; } 93 | 94 | .icon-cast:before { content: "\e841"; } 95 | 96 | .icon-chevron-down:before { content: "\e842"; } 97 | 98 | .icon-chevron-left:before { content: "\e843"; } 99 | 100 | .icon-chevron-right:before { content: "\e844"; } 101 | 102 | .icon-chevron-up:before { content: "\e845"; } 103 | 104 | .icon-chevrons-down:before { content: "\e846"; } 105 | 106 | .icon-chevrons-right:before { content: "\e847"; } 107 | 108 | .icon-chevrons-up:before { content: "\e848"; } 109 | 110 | .icon-chevrons-left:before { content: "\e849"; } 111 | 112 | .icon-circle:before { content: "\e84a"; } 113 | 114 | .icon-clipboard:before { content: "\e84b"; } 115 | 116 | .icon-chrome:before { content: "\e84c"; } 117 | 118 | .icon-clock:before { content: "\e84d"; } 119 | 120 | .icon-cloud-lightning:before { content: "\e84e"; } 121 | 122 | .icon-cloud-drizzle:before { content: "\e84f"; } 123 | 124 | .icon-cloud-rain:before { content: "\e850"; } 125 | 126 | .icon-cloud-off:before { content: "\e851"; } 127 | 128 | .icon-codepen:before { content: "\e852"; } 129 | 130 | .icon-cloud-snow:before { content: "\e853"; } 131 | 132 | .icon-compass:before { content: "\e854"; } 133 | 134 | .icon-copy:before { content: "\e855"; } 135 | 136 | .icon-corner-down-right:before { content: "\e856"; } 137 | 138 | .icon-corner-down-left:before { content: "\e857"; } 139 | 140 | .icon-corner-left-down:before { content: "\e858"; } 141 | 142 | .icon-corner-left-up:before { content: "\e859"; } 143 | 144 | .icon-corner-up-left:before { content: "\e85a"; } 145 | 146 | .icon-corner-up-right:before { content: "\e85b"; } 147 | 148 | .icon-corner-right-down:before { content: "\e85c"; } 149 | 150 | .icon-corner-right-up:before { content: "\e85d"; } 151 | 152 | .icon-cpu:before { content: "\e85e"; } 153 | 154 | .icon-credit-card:before { content: "\e85f"; } 155 | 156 | .icon-crosshair:before { content: "\e860"; } 157 | 158 | .icon-disc:before { content: "\e861"; } 159 | 160 | .icon-delete:before { content: "\e862"; } 161 | 162 | .icon-download-cloud:before { content: "\e863"; } 163 | 164 | .icon-download:before { content: "\e864"; } 165 | 166 | .icon-droplet:before { content: "\e865"; } 167 | 168 | .icon-edit-:before { content: "\e866"; } 169 | 170 | .icon-edit:before { content: "\e867"; } 171 | 172 | .icon-edit-1:before { content: "\e868"; } 173 | 174 | .icon-external-link:before { content: "\e869"; } 175 | 176 | .icon-eye:before { content: "\e86a"; } 177 | 178 | .icon-feather:before { content: "\e86b"; } 179 | 180 | .icon-facebook:before { content: "\e86c"; } 181 | 182 | .icon-file-minus:before { content: "\e86d"; } 183 | 184 | .icon-eye-off:before { content: "\e86e"; } 185 | 186 | .icon-fast-forward:before { content: "\e86f"; } 187 | 188 | .icon-file-text:before { content: "\e870"; } 189 | 190 | .icon-film:before { content: "\e871"; } 191 | 192 | .icon-file:before { content: "\e872"; } 193 | 194 | .icon-file-plus:before { content: "\e873"; } 195 | 196 | .icon-folder:before { content: "\e874"; } 197 | 198 | .icon-filter:before { content: "\e875"; } 199 | 200 | .icon-flag:before { content: "\e876"; } 201 | 202 | .icon-globe:before { content: "\e877"; } 203 | 204 | .icon-grid:before { content: "\e878"; } 205 | 206 | .icon-heart:before { content: "\e879"; } 207 | 208 | .icon-home:before { content: "\e87a"; } 209 | 210 | .icon-github:before { content: "\e87b"; } 211 | 212 | .icon-image:before { content: "\e87c"; } 213 | 214 | .icon-inbox:before { content: "\e87d"; } 215 | 216 | .icon-layers:before { content: "\e87e"; } 217 | 218 | .icon-info:before { content: "\e87f"; } 219 | 220 | .icon-instagram:before { content: "\e880"; } 221 | 222 | .icon-layout:before { content: "\e881"; } 223 | 224 | .icon-link-:before { content: "\e882"; } 225 | 226 | .icon-life-buoy:before { content: "\e883"; } 227 | 228 | .icon-link:before { content: "\e884"; } 229 | 230 | .icon-log-in:before { content: "\e885"; } 231 | 232 | .icon-list:before { content: "\e886"; } 233 | 234 | .icon-lock:before { content: "\e887"; } 235 | 236 | .icon-log-out:before { content: "\e888"; } 237 | 238 | .icon-loader:before { content: "\e889"; } 239 | 240 | .icon-mail:before { content: "\e88a"; } 241 | 242 | .icon-maximize-:before { content: "\e88b"; } 243 | 244 | .icon-map:before { content: "\e88c"; } 245 | 246 | .icon-maximize:before { content: "\e88d"; } 247 | 248 | .icon-map-pin:before { content: "\e88e"; } 249 | 250 | .icon-menu:before { content: "\e88f"; } 251 | 252 | .icon-message-circle:before { content: "\e890"; } 253 | 254 | .icon-message-square:before { content: "\e891"; } 255 | 256 | .icon-minimize-:before { content: "\e892"; } 257 | 258 | .icon-mic-off:before { content: "\e893"; } 259 | 260 | .icon-minus-circle:before { content: "\e894"; } 261 | 262 | .icon-mic:before { content: "\e895"; } 263 | 264 | .icon-minus-square:before { content: "\e896"; } 265 | 266 | .icon-minus:before { content: "\e897"; } 267 | 268 | .icon-moon:before { content: "\e898"; } 269 | 270 | .icon-monitor:before { content: "\e899"; } 271 | 272 | .icon-more-vertical:before { content: "\e89a"; } 273 | 274 | .icon-more-horizontal:before { content: "\e89b"; } 275 | 276 | .icon-move:before { content: "\e89c"; } 277 | 278 | .icon-music:before { content: "\e89d"; } 279 | 280 | .icon-navigation-:before { content: "\e89e"; } 281 | 282 | .icon-navigation:before { content: "\e89f"; } 283 | 284 | .icon-octagon:before { content: "\e8a0"; } 285 | 286 | .icon-package:before { content: "\e8a1"; } 287 | 288 | .icon-pause-circle:before { content: "\e8a2"; } 289 | 290 | .icon-pause:before { content: "\e8a3"; } 291 | 292 | .icon-percent:before { content: "\e8a4"; } 293 | 294 | .icon-phone-call:before { content: "\e8a5"; } 295 | 296 | .icon-phone-forwarded:before { content: "\e8a6"; } 297 | 298 | .icon-phone-missed:before { content: "\e8a7"; } 299 | 300 | .icon-phone-off:before { content: "\e8a8"; } 301 | 302 | .icon-phone-incoming:before { content: "\e8a9"; } 303 | 304 | .icon-phone:before { content: "\e8aa"; } 305 | 306 | .icon-phone-outgoing:before { content: "\e8ab"; } 307 | 308 | .icon-pie-chart:before { content: "\e8ac"; } 309 | 310 | .icon-play-circle:before { content: "\e8ad"; } 311 | 312 | .icon-play:before { content: "\e8ae"; } 313 | 314 | .icon-plus-square:before { content: "\e8af"; } 315 | 316 | .icon-plus-circle:before { content: "\e8b0"; } 317 | 318 | .icon-plus:before { content: "\e8b1"; } 319 | 320 | .icon-pocket:before { content: "\e8b2"; } 321 | 322 | .icon-printer:before { content: "\e8b3"; } 323 | 324 | .icon-power:before { content: "\e8b4"; } 325 | 326 | .icon-radio:before { content: "\e8b5"; } 327 | 328 | .icon-repeat:before { content: "\e8b6"; } 329 | 330 | .icon-refresh-ccw:before { content: "\e8b7"; } 331 | 332 | .icon-rewind:before { content: "\e8b8"; } 333 | 334 | .icon-rotate-ccw:before { content: "\e8b9"; } 335 | 336 | .icon-refresh-cw:before { content: "\e8ba"; } 337 | 338 | .icon-rotate-cw:before { content: "\e8bb"; } 339 | 340 | .icon-save:before { content: "\e8bc"; } 341 | 342 | .icon-search:before { content: "\e8bd"; } 343 | 344 | .icon-server:before { content: "\e8be"; } 345 | 346 | .icon-scissors:before { content: "\e8bf"; } 347 | 348 | .icon-share-:before { content: "\e8c0"; } 349 | 350 | .icon-share:before { content: "\e8c1"; } 351 | 352 | .icon-shield:before { content: "\e8c2"; } 353 | 354 | .icon-settings:before { content: "\e8c3"; } 355 | 356 | .icon-skip-back:before { content: "\e8c4"; } 357 | 358 | .icon-shuffle:before { content: "\e8c5"; } 359 | 360 | .icon-sidebar:before { content: "\e8c6"; } 361 | 362 | .icon-skip-forward:before { content: "\e8c7"; } 363 | 364 | .icon-slack:before { content: "\e8c8"; } 365 | 366 | .icon-slash:before { content: "\e8c9"; } 367 | 368 | .icon-smartphone:before { content: "\e8ca"; } 369 | 370 | .icon-square:before { content: "\e8cb"; } 371 | 372 | .icon-speaker:before { content: "\e8cc"; } 373 | 374 | .icon-star:before { content: "\e8cd"; } 375 | 376 | .icon-stop-circle:before { content: "\e8ce"; } 377 | 378 | .icon-sun:before { content: "\e8cf"; } 379 | 380 | .icon-sunrise:before { content: "\e8d0"; } 381 | 382 | .icon-tablet:before { content: "\e8d1"; } 383 | 384 | .icon-tag:before { content: "\e8d2"; } 385 | 386 | .icon-sunset:before { content: "\e8d3"; } 387 | 388 | .icon-target:before { content: "\e8d4"; } 389 | 390 | .icon-thermometer:before { content: "\e8d5"; } 391 | 392 | .icon-thumbs-up:before { content: "\e8d6"; } 393 | 394 | .icon-thumbs-down:before { content: "\e8d7"; } 395 | 396 | .icon-toggle-left:before { content: "\e8d8"; } 397 | 398 | .icon-toggle-right:before { content: "\e8d9"; } 399 | 400 | .icon-trash-:before { content: "\e8da"; } 401 | 402 | .icon-trash:before { content: "\e8db"; } 403 | 404 | .icon-trending-up:before { content: "\e8dc"; } 405 | 406 | .icon-trending-down:before { content: "\e8dd"; } 407 | 408 | .icon-triangle:before { content: "\e8de"; } 409 | 410 | .icon-type:before { content: "\e8df"; } 411 | 412 | .icon-twitter:before { content: "\e8e0"; } 413 | 414 | .icon-upload:before { content: "\e8e1"; } 415 | 416 | .icon-umbrella:before { content: "\e8e2"; } 417 | 418 | .icon-upload-cloud:before { content: "\e8e3"; } 419 | 420 | .icon-unlock:before { content: "\e8e4"; } 421 | 422 | .icon-user-check:before { content: "\e8e5"; } 423 | 424 | .icon-user-minus:before { content: "\e8e6"; } 425 | 426 | .icon-user-plus:before { content: "\e8e7"; } 427 | 428 | .icon-user-x:before { content: "\e8e8"; } 429 | 430 | .icon-user:before { content: "\e8e9"; } 431 | 432 | .icon-users:before { content: "\e8ea"; } 433 | 434 | .icon-video-off:before { content: "\e8eb"; } 435 | 436 | .icon-video:before { content: "\e8ec"; } 437 | 438 | .icon-voicemail:before { content: "\e8ed"; } 439 | 440 | .icon-volume-x:before { content: "\e8ee"; } 441 | 442 | .icon-volume-:before { content: "\e8ef"; } 443 | 444 | .icon-volume-1:before { content: "\e8f0"; } 445 | 446 | .icon-volume:before { content: "\e8f1"; } 447 | 448 | .icon-watch:before { content: "\e8f2"; } 449 | 450 | .icon-wifi:before { content: "\e8f3"; } 451 | 452 | .icon-x-square:before { content: "\e8f4"; } 453 | 454 | .icon-wind:before { content: "\e8f5"; } 455 | 456 | .icon-x:before { content: "\e8f6"; } 457 | 458 | .icon-x-circle:before { content: "\e8f7"; } 459 | 460 | .icon-zap:before { content: "\e8f8"; } 461 | 462 | .icon-zoom-in:before { content: "\e8f9"; } 463 | 464 | .icon-zoom-out:before { content: "\e8fa"; } 465 | 466 | .icon-command:before { content: "\e8fb"; } 467 | 468 | .icon-cloud:before { content: "\e8fc"; } 469 | 470 | .icon-hash:before { content: "\e8fd"; } 471 | 472 | .icon-headphones:before { content: "\e8fe"; } 473 | 474 | -------------------------------------------------------------------------------- /images/peters.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/images/peters.png -------------------------------------------------------------------------------- /images/techdebt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/images/techdebt.png -------------------------------------------------------------------------------- /makebook.sh: -------------------------------------------------------------------------------- 1 | pandoc \ 2 | text/toc.md \ 3 | text/preface.md \ 4 | text/techdebt.md \ 5 | text/iterating.md \ 6 | text/occam.md \ 7 | text/alignment.md \ 8 | text/hiring.md \ 9 | text/effort.md \ 10 | text/tracker.md \ 11 | text/whatmakesagoodmanager.md \ 12 | text/methodologies.md \ 13 | text/decisions.md \ 14 | text/integration.md \ 15 | text/askingforinformation.md \ 16 | text/technologies.md \ 17 | text/peoplevstech.md \ 18 | text/agile.md \ 19 | text/yourmanager.md \ 20 | text/deadlines.md \ 21 | text/compensation.md \ 22 | text/hours.md \ 23 | text/remote.md \ 24 | text/juniors.md \ 25 | text/managingmanagers.md \ 26 | text/scale.md \ 27 | text/qa.md \ 28 | text/research.md \ 29 | text/feedback.md \ 30 | text/meetings.md \ 31 | text/culture.md \ 32 | -o book.epub \ 33 | --epub-metadata text/title.txt 34 | 35 | 36 | 37 | -------------------------------------------------------------------------------- /text/agile.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/agile.md -------------------------------------------------------------------------------- /text/alignment.md: -------------------------------------------------------------------------------- 1 | # Talent Alignment 2 | 3 | An engineering manager has an immense amount of responsibility. He is responsible to advance the career of all of its developers at any given moment in time. If your developers are not constantly improving and advancing their career then they will look for other engineering managers that do give them the opportunity to advance their career. 4 | 5 | This issue is often overlooked as time passes by because it's easy to ignore. As an engineering manager, you will need to analyze the career path of all of your developers and make sure that what they are in one year from now is an improved version of what they are today - both from a resume perspective and a literal perspective. 6 | 7 | As you manage more and more developers, it's easier to lose focus on some, especially those who are quiet. Therefore, you will need to plan regular career check-ups every 3 months to one year to ensure that people are happy with their career path. 8 | 9 | A good framework for doing talent management is as follows: 10 | 11 | 1. Schedule a career expectations meeting, in which you would ask the question: where do you want to be one year from now? 12 | 2. Once a quarter, make sure that reality aligns with the expectations 13 | 3. Throughout the year, make sure that you are fully aware of the career aspirations of all of your developers, so you can adjust the teams and pick the right people for the right job according to their needs. 14 | 15 | Sometimes you will need to make decisions that seem less optimal to the company by following the third point, but the reality is that if people will stay for longer, they will increase the morale of the rest of the organization, gain more expertise and require the business to invest less in extra recruiting - which means that it can eventually pan out as the more optimal decision. 16 | 17 | For example, a developer who wants to learn Scala will need twice as much time to develop a system than his counterpart who already knows Scala. But for you, the extra week of investment is worth it just for the sake of making your employees happy, not even considering the fact that learning Scala can be useful for his future in the company as well. 18 | 19 | "Maslow's hierarchy of needs" is a psychological theory proposed back in 1943 by Abraham Maslow. The theory talks about the leves and phases of personal development of a person's career in life. It starts out with the physiological needs (e.g. food, water, sleep), safety, love/belonging, esteem and finally self-actualization - in that order. People will first focus their career and worry about being able to eat, before they care about how much they feel appreciated in their workplace. 20 | 21 | Most people in the world who work at simple, repetitive jobs, get stuck before self-actualization. In the software development world however, most people reach the need for self-actualization. They want to realize their full potential and prove that they can become the most they can be. As engineering managers, we have to enable them to realize their full potential. 22 | 23 | Generally speaking, there are several ways of growing: 24 | 25 | 1. Management - probably the most obvious one, and sometimes wrongfully seems like the only way to advance one's career. Moving into management means learning a new skillset which focuses on how people work rather than how software works. People often are attracted to management as it is perceived as having more responsibility and power over people. A manager's time often can be considered more "valuable", which means people can be more appreciated and get paid more. Management is sometimes also considered as a more future-proof skill as we age, because it relies more on experience rather than agility, speed and learning ability. 26 | 2. Technical Skills - developers like to learn new things and increase their toolset and abilities. Learning is not only fun, but the more we learn new things, the better we get at being developers in general, as we gain new perspectives. Technical skills also put developers at a relative advantage over other developers, which leads to becoming more needed, and ultimately getting paid more and being more appreciated. 27 | 3. Entrepreneurship / Business Impact - entrepreneurs look at software development as a means to an end. The impact is eventually what matters, not the successful execution of the project. Such people will often enjoy working on systems that have greater impact rather than managing more people or learning more programming languages. 28 | 4. Hobbies - some people don't look at their workplace as their growth path in life at all, and only care about developing their hobbies outside of work. These people are actually the easiest to handle as they do not require career development at all. As long as they are happy in their current role, they should just stay there. 29 | 30 | As an engineering manager, you should identify which avenues are the growth paths for your employees, and work using these assumptions. Often times your employees will realize they have not fully thought through what they want to achieve in life, so more frequent 1 on 1 meetings will be required until they actually feel comfortable with their career aspirations. -------------------------------------------------------------------------------- /text/askingforinformation.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/askingforinformation.md -------------------------------------------------------------------------------- /text/compensation.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/compensation.md -------------------------------------------------------------------------------- /text/culture.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/culture.md -------------------------------------------------------------------------------- /text/deadlines.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/deadlines.md -------------------------------------------------------------------------------- /text/decisions.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/decisions.md -------------------------------------------------------------------------------- /text/effort.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/effort.md -------------------------------------------------------------------------------- /text/feedback.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/feedback.md -------------------------------------------------------------------------------- /text/hiring.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/hiring.md -------------------------------------------------------------------------------- /text/hours.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/hours.md -------------------------------------------------------------------------------- /text/integration.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/integration.md -------------------------------------------------------------------------------- /text/iterating.md: -------------------------------------------------------------------------------- 1 | # Iterating towards Perfection 2 | 3 | -------------------------------------------------------------------------------- /text/juniors.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/juniors.md -------------------------------------------------------------------------------- /text/managingmanagers.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/managingmanagers.md -------------------------------------------------------------------------------- /text/meetings.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/meetings.md -------------------------------------------------------------------------------- /text/methodologies.md: -------------------------------------------------------------------------------- 1 | # Developers Fail, Methodologies Don't 2 | 3 | How do you deal with the fact that developers are inherently unreliable? 4 | 5 | I have met managers that get frustrated from these things, and think that the developers are to blame. Then, they start counting the number of failures and change their attitude to show their dissatisfaction to the point where managing the developer is impossible, and the engineer would either quit or get fired. But the reality is that developers have a certain degree of inherent uncertainty in their output, and they will always produce bugs and inaccurate code. It is on the hands of us, the engineering managers, to turn developers who make mistakes into teams that don't make mistakes. 6 | 7 | This is possible, at least to a high degree, using good software development methodologies. 8 | 9 | There are several methodologies we can incorporate so that our teams won't fail: 10 | 11 | 1. Code reviews - probably the one that would catch the least amount of failures, code reviews are important more for the sake of aligning the code to how it's supposed to be written versus finding bugs. 12 | 2. Testing - the most obvious one, but also more geared at preserving the code so it won't break. 13 | 3. Validation process - The most important and best way of ensuring that developers don't fail. The validation process is the gating process that verifies that the feature which was implemented actually meets the requirements. 14 | 15 | The validation process is the key methodology for ensuring that the output of your team is accurate. Building the validation step requires implementing as many real-world scenarios as you can think of (and that you have time to test), and then ask the developer who implemented the feature to run through. 16 | 17 | For example, a classic task for a developer would be to implement a program that writes out the fibonacci sequence. You can then ask your developer to Google the first 100 fibonacci numbers, copy then into a text file, and then use the diff tool to compare the output of their program to the result in Google. You should then ask your developer to send you the output of the diff to see the output for yourself. 18 | 19 | The key here is that you can build small ad-hoc tests that are easy for you to know what to expect, and therefore verify that the code written actually does what it's supposed to do. The difference between asking for this versus writing tests that do the same, is that tests can be wrong themselves, and tests are usually geared at checking that the logic that was written was not broken, rather than checking that the tests produce the output that was required from the product manager. 20 | 21 | -------------------------------------------------------------------------------- /text/occam.md: -------------------------------------------------------------------------------- 1 | # Occam's Razor 2 | 3 | Occam's Razor is a philosophical principle that states the following: 4 | 5 | > Suppose there exist two explanations for an occurrence. In this case the one that requires the least speculation is usually better. Another way of saying it is that the more assumptions you have to make, the more unlikely an explanation. 6 | 7 | To summarize, Occam's Razor is a theoretical tool that guides us to choose the simplest solution for a given problem that can properly solve the problem. Or in other words, don't overcomplicate the system you are building more than you must. 8 | 9 | In the software world, as we are given the requirements of the system we need to build, we are often faced with a dillema of building a generic system vs a specific system. The generic system would be more flexible, more abstract, be open to change and to new requirements, whereas the specific system will be simpler, easier to understand and maintain, hard to extend and prone to tech debt accumulation. 10 | 11 | The philisophical analogy isn't accurate of course. Occam's Razor is a guideline for choosing the "right" theory, whereas in the software development world we just aim to make a more efficient choice. 12 | 13 | It's not easy to make a decision on how generic vs how specific you should write your system as. The software development version of Occam's Razor tells us we should be focusing our efforts to build a system which is complex at just the right amount - no less, no more. It has to be at least as complex as it needs to be to fulfill the requirements, but it also should not be more complex than it should be. 14 | 15 | But what does it mean "no more complex than it should be"? There are several reasons to make a system more complex than the initial requirements require it to be: 16 | 17 | 1. Extensibility - as new features are required to be developed, a more generic system will be able to accumulate less technical debt if written properly. 18 | 2. Simplicity - more generic systems tend to be more readable and rely more on configuration rather than hard-coded logic and values. 19 | 3. Reusability - more generic systems can be reused in other places where there are other but similar requirements. Another advantage in writing reusable code is that developers can open source the code and make their system into a community supported system - both for maintenance purposes and fame/recruitment purposes. 20 | 21 | However, there are also downsides for doing this: 22 | 23 | 1. More generic systems simply require more time to design and develop. 24 | 2. Maintenance - more generic systems require more maintenance, as it often means that more changes are required in the code to get to the same result. 25 | 3. Learning curve - more generic systems require that developers learn more about how the system works before being comfortable with making changes. 26 | 4. Focus on the technology rather than the business needs - more generic systems tend to attract developers to enhance the system in ways that may not benefit the business needs directly, as there's more ability to extend and upgrade the system. A more specific system would often be focused on the specific use case at hand. 27 | 5. Throwaway code - systems tend to be temporary, so a larger investment than needed can be a waste of development effort. 28 | 29 | Throwaway code is often overlooked at development teams as they usually don't feel like they are accountable to the overall resource spend of the business. Often times the engineering manager often does not even have the ability to predict the chances of the code being thrown away. The guideline should be "don't write a generic system for the first version of the system". When you're a start-up - it's better to get something out the door sooner rather than later, and you'll be lucky if something sticks. 30 | 31 | Here's an example: Let's say you have the option of writing three specific systems and one generic system using one man-month. It would be better to write all three specific systems, and later on understand that only system #2 needs to be developed into a generic system (which costs us two months), compared to spending three months of writing three generic systems and throwing away two of them. Of course this is a very theoretical example, but the example should guide you to look at the ratio between writing a generic system versus a specific system, as well as the chances for the system to stick around for the long term according to the needs of the business. Once you can calculate the odds, you can make the decision. 32 | 33 | -------------------------------------------------------------------------------- /text/peoplevstech.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/peoplevstech.md -------------------------------------------------------------------------------- /text/preface.md: -------------------------------------------------------------------------------- 1 | # Preface - Why is managing developers hard? 2 | 3 | Managing software development teams has become a profession of its own. But, unlike software development or business school, there wasn’t a point in time where the world stopped to think for a second and realize this profession can and should be thought. In fact - the world is still in a constant state of guesswork and on-job-training for management. The only way to actually learn how to manage software developers today - is to try. 4 | 5 | But after you try, how do you know that you’re doing a good job? The first thing I noticed about managing developers is that it requires a lot of effort, much more than I have originally anticipated. But the worse part is that unlike software development - where you can quantify if a developer is doing a good job pretty easily - quantifying the success of a software manager is much harder. And if you know what makes a software development manager good, then you will be able to improve, as a manager. 6 | 7 | This book is about sharing the things I have learned managing software developers, software team leaders, software tech leads and software project managers, as part of my journey - from starting a company, hiring the first employees, promoting them, selling the company to a large enterprise, and operating within it, while continuing to build the team. 8 | 9 | In this book, I will aim to give you some tools so that you could answer questions like: 10 | 11 | * How do you make your employees happy? 12 | * How much do you invest in writing software? 13 | * How do you estimate efforts and meet deadlines? 14 | * How do you operate in an environment where product requests constantly change and employees give variable output? 15 | * How do you scale your team? 16 | * How do you test your software? 17 | * Which technologies should you choose that best fit the team? 18 | 19 | The chapters in the book are not ordered by a specific ordering. This book is more of a “handbook” rather than a story - although I will give stories and examples from time to time from my past experience. I hope you will enjoy reading it as much as I enjoyed writing it! 20 | 21 | -------------------------------------------------------------------------------- /text/qa.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/qa.md -------------------------------------------------------------------------------- /text/remote.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/remote.md -------------------------------------------------------------------------------- /text/research.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/research.md -------------------------------------------------------------------------------- /text/scale.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/scale.md -------------------------------------------------------------------------------- /text/techdebt.md: -------------------------------------------------------------------------------- 1 | # The 80/20 Approach and Managing Technical Debt 2 | 3 | Perhaps the most commonly used software development methodology is the 80/20 approach. I am sure you have heard of it before - but if you haven't, there's still a good chance you are doing it but just calling it something else. 4 | 5 | The 80/20 approach states that the most efficient way of starting out is not by doing things perfectly, but rather doing them good enough to start out with, therefore gaining immense benefit over little time. 80/20 means that you could usually gain 80% of the benefit of doing something by investing 20% of the time required to do it perfectly, whereas the remaining 20% would take you 80% of the time. 6 | 7 | A good example is cleaning up files on your hard drive. The correct approach would not be to go over ALL of the files on your hard drive, but rather sorting them by size, investing a few minutes reviewing only the large files, and deleting those that you don’t need anymore. The realization of ordering the files by significance saves us a lot of time because using the same amount of time on smaller files will yield a smaller outcome. This realization is the secret behind the 80/20 approach - do what’s important first, and stop when things become less efficient, in favor of utilizing your time for other things. 8 | 9 | The same exact approach can be applied to software engineering and management. The most classic example of where the 80/20 approach should be applied, is when developing software. This is because of two reasons: 10 | 11 | 1. Product requirements constantly change, especially in start-ups. A product requirement dictates which software should be implemented and how. This means that assuming that your code will stay relevant is not a good assumption. Therefore - why should you invest a lot of time perfecting software that there’s a high chance you will end up not using anymore? 12 | 2. Technical teams learn what to invest in and what not to invest in during the development cycle, and not in the design phase, because it’s just too difficult to completely understand what is the optimal design of a system. 13 | 14 | This is usually why building prototypes and not investing in software is actually a good thing and not a bad thing. As you progress with software development, you will find out that you and/or your team has new ideas for improvements all the time. You must be always committed to stashing those ideas to the backlog instead of pulling the deadlines further ahead. 15 | 16 | The downside of writing sloppy code is obvious - technical debt. Bad code is unmaintainable, and sometimes requires not only refactoring to fix but rather full rewrites to get things right. There’s a misconception that this is a bad thing. It is not. Rewriting code might end up the right thing to do, because of a few reasons: 17 | 18 | 1. It is faster to rewrite code rather than to refactor it, because rewriting it gives full visibility and control over to the programmer and because he does not need to worry about breaking an existing system. 19 | 2. It gives you the opportunity to rethink more things, that might end up saving more time by further reducing technical debt. 20 | 3. It gives the developer the agility to write the code in a way that is more convenient for him, for example using a more suitable programming language. 21 | 22 | What’s important to realize is that you should not be attached to your code - writing the code is merely a way of achieving your goal. Whenever your goal can be achieved quicker by rewriting things, it should always be considered as an option. This is especially true in today’s world where open source dominates and a lot of systems can achieve simplicity by using open source components and tools that were developed in-house just because they weren’t available at the time of writing the original code. 23 | 24 | But when does this approach impose a problem that needs to be addressed? when rewriting the code is too much work that the business cannot prioritize. In this case, the code must be fixed slowly, and over time. This is done by building a solid plan that allows a software manager to take small chunks of technical debt and get rid of them by refactoring or fixing the code as part of larger features. When the system is mature enough and the code has proven to be required for the business, you should commit to yourself that every new feature will only reduce technical debt, instead of increase it. 25 | 26 | ![Technical Debt](images/techdebt.png) 27 | 28 | Writing the code without technical debt from the beginning does save the time required to remove the technical debt later on. But statistically, the code that ends up being used over time is hard to identify at first, which is why you should usually assume that it is OK to accumulate technical debt. 29 | 30 | Another approach to handling technical debt is to pursuade the business stakeholders and product managers that R&D needs to go into a year-long project to rearchitect the existing system. In this case, an engineering manager will effectively take the role of the "technical product manager" and plan a new system that will take on the older one, and will have to justify the resource and time allocation that is required to do so. This approach is only possible after the existing system has either proven to be required in the long term future of the company, or that the current operational overhead must be immediately addressed so that the existing business will not be negatively impacted. For example - if immediate scaling is required but the system that was built is not scalable, then the decision makers will simply have to agree to the project. 31 | 32 | If the complete rewrite approach is taken, then an engineering manager would likely have to present a solid, time boxed plan, which has very strict goals and advantages over the current system. 33 | 34 | -------------------------------------------------------------------------------- /text/technologies.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/technologies.md -------------------------------------------------------------------------------- /text/time.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/time.md -------------------------------------------------------------------------------- /text/title.txt: -------------------------------------------------------------------------------- 1 | --- 2 | title: 3 | - type: main 4 | text: Managing Software Developers 5 | - type: subtitle 6 | text: And why is it so hard? 7 | 8 | creator: 9 | - role: author 10 | text: Ron Reiter 11 | - role: editor 12 | text: Sarah Jones 13 | 14 | rights: 2018 Ron Reiter 15 | publisher: Ron Reiter 16 | language: en-US 17 | -------------------------------------------------------------------------------- /text/toc.md: -------------------------------------------------------------------------------- 1 | % Managing Software Developers 2 | % Ron Reiter 3 | 4 | # Table of Contents 5 | 6 | 1. [Preface - Why is managing developers hard?](preface.md) 7 | 2. [Technical Debt](techdebt.md) 8 | 3. [Iterating towards Perfection](iterating.md) 9 | 4. [Occam's Razor](occam.md) 10 | 5. [Talent Alignment](alignment.md) 11 | 6. [The Hiring Process](hiring.md) 12 | 7. [Effort Estimation](effort.md) 13 | 8. [Picking a good issue tracker](tracker.md) 14 | 9. [What makes a good Software Development Manager?](whatmakesagoodmanager.md) (peters principle) - PUT THIS FIRST! 15 | 10. [Developers fail, Methodologies don't](methodologies.md) 16 | 11. [Spaces vs Tabs - or how to make decisions](decisions.md) 17 | 12. [Integration Tests as a method of Management](integration.md) 18 | 13. [Asking for information as a method of Management](askingforinformation.md) 19 | 14. [Picking Technologies](technologies.md) 20 | 15. [People Management vs Technical Management](peoplevstech.md) 21 | 16. [The Agile Software Development Process](agile.md) (Scrum or Kanban?) 22 | 17. [The Relationship with Your Manager](yourmanager.md) 23 | 18. [Meeting the Deadlines: Underpromise and Overdeliver](deadlines.md) 24 | 19. [Compensation](compensation.md) 25 | 20. [Working from home and working hours](hours.md) 26 | 21. [Managing remote developers](remote.md) 27 | 22. [Junior Developers](juniors.md) (you need them!) 28 | 23. [Managing Software Managers](managingmanagers.md) 29 | 24. [Scaling Your Team - Trust, delegate and stop micro-managing](scale.md) (Productive Work vs Management Work) 30 | 25. [Do you need a QA team?](qa.md) (CI/CD) 31 | 26. [Managing Research Projects](research.md) 32 | 27. [Giving Feedback](feedback.md) 33 | 28. [Meetings](meetings.md) 34 | 29. [Culture](culture.md) 35 | 30. [Time Management](time.md) 36 | 37 | 38 | -------------------------------------------------------------------------------- /text/tracker.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/tracker.md -------------------------------------------------------------------------------- /text/whatmakesagoodmanager.md: -------------------------------------------------------------------------------- 1 | # What makes a good manager? 2 | 3 | Peter's principle states that the selection of a candidate for a position is based on the candidate's performance in their current role, rather than on abilities relevant to the intended role. Thus, employees only stop being promoted once they can no longer perform effectively, and "managers rise to the level of their incompetence". 4 | 5 | ![Technical Debt](images/techdebt.png) 6 | -------------------------------------------------------------------------------- /text/yourmanager.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ronreiter/managing-software-developers/ca9334f10e2a4405f62888a1dac81224b151829d/text/yourmanager.md --------------------------------------------------------------------------------