davidbgk
/
larlet-fr-david-cache
Watch 1
Star 0
Fork 0
Code Releases 0 Activity
A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
42 Commits
1 Branch
Tree: 2e4d51a7b7
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '2e4d51a7b7'
${ noResults }
larlet-fr-david-cache/cache/94698ca94c727a3688d38b8d365.../index.html

index.html 68KB
Raw Blame History

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196 
  1. <!doctype html><!-- This is a valid HTML5 document. -->

  2. <!-- Screen readers, SEO, extensions and so on. -->

  3. <html lang=fr>

  4. <!-- Has to be within the first 1024 bytes, hence before the <title>

  5.   See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->

  6. <meta charset=utf-8>

  7. <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->

  8. <!-- The viewport meta is quite crowded and we are responsible for that.

  9.   See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->

  10. <meta name=viewport content="width=device-width,minimum-scale=1,initial-scale=1,shrink-to-fit=no">

  11. <!-- Required to make a valid HTML5 document. -->

  12. <title>The Webflow Tech Lead Guide (archive) — David Larlet</title>

  13. <!-- Generated from https://realfavicongenerator.net/ such a mess. -->

  14. <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons/apple-touch-icon.png">

  15. <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons/favicon-32x32.png">

  16. <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons/favicon-16x16.png">

  17. <link rel="manifest" href="/manifest.json">

  18. <link rel="mask-icon" href="/static/david/icons/safari-pinned-tab.svg" color="#5bbad5">

  19. <link rel="shortcut icon" href="/static/david/icons/favicon.ico">

  20. <meta name="apple-mobile-web-app-title" content="David Larlet">

  21. <meta name="application-name" content="David Larlet">

  22. <meta name="msapplication-TileColor" content="#da532c">

  23. <meta name="msapplication-config" content="/static/david/icons/browserconfig.xml">

  24. <meta name="theme-color" content="#f0f0ea">

  25. <!-- That good ol' feed, subscribe :p. -->

  26. <link rel=alternate type="application/atom+xml" title=Feed href="/david/log/">

  27. 

  28.   <meta name="robots" content="noindex, nofollow">

  29.   <meta content="origin-when-cross-origin" name="referrer">

  30.   <!-- Canonical URL for SEO purposes -->

  31.   <link rel="canonical" href="https://github.com/webflow/leadership/blob/master/tech_lead.md">

  32. 

  33. <style>

  34. /* http://meyerweb.com/eric/tools/css/reset/ */

  35. html, body, div, span,

  36. h1, h2, h3, h4, h5, h6, p, blockquote, pre,

  37. a, abbr, address, big, cite, code,

  38. del, dfn, em, img, ins,

  39. small, strike, strong, tt, var,

  40. dl, dt, dd, ol, ul, li,

  41. fieldset, form, label, legend,

  42. table, caption, tbody, tfoot, thead, tr, th, td,

  43. article, aside, canvas, details, embed,

  44. figure, figcaption, footer, header, hgroup,

  45. menu, nav, output, ruby, section, summary,

  46. time, mark, audio, video {

  47.   margin: 0;

  48.   padding: 0;

  49.   border: 0;

  50.   font-size: 100%;

  51.   font: inherit;

  52.   vertical-align: baseline;

  53. }

  54. /* HTML5 display-role reset for older browsers */

  55. article, aside, details, figcaption, figure,

  56. footer, header, hgroup, menu, nav, section { display: block; }

  57. body { line-height: 1; }

  58. blockquote, q { quotes: none; }

  59. blockquote:before, blockquote:after,

  60. q:before, q:after {

  61.   content: '';

  62.   content: none;

  63. }

  64. table {

  65.   border-collapse: collapse;

  66.   border-spacing: 0;

  67. }

  68. 

  69. /* http://practicaltypography.com/equity.html */

  70. /* https://calendar.perfplanet.com/2016/no-font-face-bulletproof-syntax/ */

  71. /* https://www.filamentgroup.com/lab/js-web-fonts.html */

  72. @font-face {

  73.   font-family: 'EquityTextB';

  74.   src: url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff2') format('woff2'),

  75.        url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff') format('woff');

  76.   font-weight: 300;

  77.   font-style: normal;

  78.   font-display: swap;

  79. }

  80. @font-face {

  81.   font-family: 'EquityTextB';

  82.   src: url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff2') format('woff2'),

  83.        url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff') format('woff');

  84.   font-weight: 300;

  85.   font-style: italic;

  86.   font-display: swap;

  87. }

  88. @font-face {

  89.   font-family: 'EquityTextB';

  90.   src: url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff2') format('woff2'),

  91.        url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff') format('woff');

  92.   font-weight: 700;

  93.   font-style: normal;

  94.   font-display: swap;

  95. }

  96. 

  97. @font-face {

  98.   font-family: 'ConcourseT3';

  99.   src: url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff2') format('woff2'),

  100.        url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff') format('woff');

  101.   font-weight: 300;

  102.   font-style: normal;

  103.   font-display: swap;

  104. }

  105. 

  106. 

  107. /* http://practice.typekit.com/lesson/caring-about-opentype-features/ */

  108. body {

  109.   /* http://www.cssfontstack.com/ Palatino 99% Win 86% Mac */

  110.   font-family: "EquityTextB", Palatino, serif;

  111.   background-color: #f0f0ea;

  112.   color: #07486c;

  113.   font-kerning: normal;

  114.   -moz-osx-font-smoothing: grayscale;

  115.   -webkit-font-smoothing: subpixel-antialiased;

  116.   text-rendering: optimizeLegibility;

  117.   font-variant-ligatures: common-ligatures contextual;

  118.   font-feature-settings: "kern", "liga", "clig", "calt";

  119. }

  120. pre, code, kbd, samp, var, tt {

  121.   font-family: 'TriplicateT4c', monospace;

  122. }

  123. em {

  124.   font-style: italic;

  125.   color: #323a45;

  126. }

  127. strong {

  128.   font-weight: bold;

  129.   color: black;

  130. }

  131. nav {

  132.   background-color: #323a45;

  133.   color: #f0f0ea;

  134.   display: flex;

  135.   justify-content: space-around;

  136.   padding: 1rem .5rem;

  137. }

  138.   nav:last-child {

  139.     border-bottom: 1vh solid #2d7474;

  140.   }

  141.   nav a {

  142.     color: #f0f0ea;

  143.   }

  144.   nav abbr {

  145.     border-bottom: 1px dotted white;

  146.   }

  147. 

  148. h1 {

  149.   border-top: 1vh solid #2d7474;

  150.   border-bottom: .2vh dotted #2d7474;

  151.   background-color: #e3e1e1;

  152.   color: #323a45;

  153.   text-align: center;

  154.   padding: 5rem 0 4rem 0;

  155.   width: 100%;

  156.   font-family: 'ConcourseT3';

  157.   display: flex;

  158.   flex-direction: column;

  159. }

  160.   h1.single {

  161.     padding-bottom: 10rem;

  162.   }

  163.   h1 span {

  164.     position: absolute;

  165.     top: 1vh;

  166.     left: 20%;

  167.     line-height: 0;

  168.   }

  169.     h1 span a {

  170.       line-height: 1.7;

  171.       padding: 1rem 1.2rem .6rem 1.2rem;

  172.       border-radius: 0 0 6% 6%;

  173.       background: #2d7474;

  174.       font-size: 1.3rem;

  175.       color: white;

  176.       text-decoration: none;

  177.     }

  178. h2 {

  179.   margin: 4rem 0 1rem;

  180.   border-top: .2vh solid #2d7474;

  181.   padding-top: 1vh;

  182. }

  183. h3 {

  184.   text-align: center;

  185.   margin: 3rem 0 .75em;

  186. }

  187. hr {

  188.   height: .4rem;

  189.   width: .4rem;

  190.   border-radius: .4rem;

  191.   background: #07486c;

  192.   margin: 2.5rem auto;

  193. }

  194. time {

  195.   display: bloc;

  196.   margin-left: 0 !important;

  197. }

  198. ul, ol {

  199.   margin: 2rem;

  200. }

  201. ul {

  202.   list-style-type: square;

  203. }

  204. a {

  205.   text-decoration-skip-ink: auto;

  206.   text-decoration-thickness: 0.05em;

  207.   text-underline-offset: 0.09em;

  208. }

  209. article {

  210.   max-width: 50rem;

  211.   display: flex;

  212.   flex-direction: column;

  213.   margin: 2rem auto;

  214. }

  215.   article.single {

  216.     border-top: .2vh dotted #2d7474;

  217.     margin: -6rem auto 1rem auto;

  218.     background: #f0f0ea;

  219.     padding: 2rem;

  220.   }

  221.   article p:last-child {

  222.     margin-bottom: 1rem;

  223.   }

  224. p {

  225.   padding: 0 .5rem;

  226.   margin-left: 3rem;

  227. }

  228.   p + p,

  229.   figure + p {

  230.     margin-top: 2rem;

  231.   }

  232. 

  233. blockquote {

  234.   background-color: #e3e1e1;

  235.   border-left: .5vw solid #2d7474;

  236.   display: flex;

  237.   flex-direction: column;

  238.   align-items: center;

  239.   padding: 1rem;

  240.   margin: 1.5rem;

  241. }

  242.   blockquote cite {

  243.     font-style: italic;

  244.   }

  245.   blockquote p {

  246.     margin-left: 0;

  247.   }

  248. 

  249. figure {

  250.   border-top: .2vh solid #2d7474;

  251.   background-color: #e3e1e1;

  252.   text-align: center;

  253.   padding: 1.5rem 0;

  254.   margin: 1rem 0 0;

  255.   font-size: 1.5rem;

  256.   width: 100%;

  257. }

  258.   figure img {

  259.     max-width: 250px;

  260.     max-height: 250px;

  261.     border: .5vw solid #323a45;

  262.     padding: 1px;

  263.   }

  264. figcaption {

  265.   padding: 1rem;

  266.   line-height: 1.4;

  267. }

  268. aside {

  269.   display: flex;

  270.   flex-direction: column;

  271.   background-color: #e3e1e1;

  272.   padding: 1rem 0;

  273.   border-bottom: .2vh solid #07486c;

  274. }

  275.   aside p {

  276.     max-width: 50rem;

  277.     margin: 0 auto;

  278.   }

  279. 

  280. /* https://fvsch.com/code/css-locks/ */

  281. p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {

  282.   font-size: 1rem;

  283.   line-height: calc( 1.5em + 0.2 * 1rem );

  284. }

  285. h1 {

  286.   font-size: 1.9rem;

  287.   line-height: calc( 1.2em + 0.2 * 1rem );

  288. }

  289. h2 {

  290.   font-size: 1.6rem;

  291.   line-height: calc( 1.3em + 0.2 * 1rem );

  292. }

  293. h3 {

  294.   font-size: 1.35rem;

  295.   line-height: calc( 1.4em + 0.2 * 1rem );

  296. }

  297. @media (min-width: 20em) {

  298.   /* The (100vw - 20rem) / (50 - 20) part

  299.      resolves to 0-1rem, depending on the

  300.      viewport width (between 20em and 50em). */

  301.   p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {

  302.     font-size: calc( 1rem + .6 * (100vw - 20rem) / (50 - 20) );

  303.     line-height: calc( 1.5em + 0.2 * (100vw - 50rem) / (20 - 50) );

  304.     margin-left: 0;

  305.   }

  306.   h1 {

  307.     font-size: calc( 1.9rem + 1.5 * (100vw - 20rem) / (50 - 20) );

  308.     line-height: calc( 1.2em + 0.2 * (100vw - 50rem) / (20 - 50) );

  309.   }

  310.   h2 {

  311.     font-size: calc( 1.5rem + 1.5 * (100vw - 20rem) / (50 - 20) );

  312.     line-height: calc( 1.3em + 0.2 * (100vw - 50rem) / (20 - 50) );

  313.   }

  314.   h3 {

  315.     font-size: calc( 1.35rem + 1.5 * (100vw - 20rem) / (50 - 20) );

  316.     line-height: calc( 1.4em + 0.2 * (100vw - 50rem) / (20 - 50) );

  317.   }

  318. }

  319. @media (min-width: 50em) {

  320.   /* The right part of the addition *must* be a

  321.      rem value. In this example we *could* change

  322.      the whole declaration to font-size:2.5rem,

  323.      but if our baseline value was not expressed

  324.      in rem we would have to use calc. */

  325.   p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {

  326.     font-size: calc( 1rem + .6 * 1rem );

  327.     line-height: 1.5em;

  328.   }

  329.   p, li, pre, details {

  330.     margin-left: 3rem;

  331.   }

  332.   h1 {

  333.     font-size: calc( 1.9rem + 1.5 * 1rem );

  334.     line-height: 1.2em;

  335.   }

  336.   h2 {

  337.     font-size: calc( 1.5rem + 1.5 * 1rem );

  338.     line-height: 1.3em;

  339.   }

  340.   h3 {

  341.     font-size: calc( 1.35rem + 1.5 * 1rem );

  342.     line-height: 1.4em;

  343.   }

  344.   figure img {

  345.     max-width: 500px;

  346.     max-height: 500px;

  347.   }

  348. }

  349. 

  350. figure.unsquared {

  351.   margin-bottom: 1.5rem;

  352. }

  353.   figure.unsquared img {

  354.     height: inherit;

  355.   }

  356. 

  357. 

  358. 

  359. @media print {

  360.   body { font-size: 100%; }

  361.   a:after { content: " (" attr(href) ")"; }

  362.   a, a:link, a:visited, a:after {

  363.     text-decoration: underline;

  364.     text-shadow: none !important;

  365.     background-image: none !important;

  366.     background: white;

  367.     color: black;

  368.   }

  369.   abbr[title] { border-bottom: 0; }

  370.   abbr[title]:after { content: " (" attr(title) ")"; }

  371.   img { page-break-inside: avoid; }

  372.   @page { margin: 2cm .5cm; }

  373.   h1, h2, h3 { page-break-after: avoid; }

  374.   p3 { orphans: 3; widows: 3; }

  375.   img {

  376.     max-width: 250px !important;

  377.     max-height: 250px !important;

  378.   }

  379.   nav, aside { display: none; }

  380. }

  381. 

  382. ul.with_columns {

  383.   column-count: 1;

  384. }

  385. @media (min-width: 20em) {

  386.   ul.with_columns {

  387.     column-count: 2;

  388.   }

  389. }

  390. @media (min-width: 50em) {

  391.   ul.with_columns {

  392.     column-count: 3;

  393.   }

  394. }

  395. ul.with_two_columns {

  396.   column-count: 1;

  397. }

  398. @media (min-width: 20em) {

  399.   ul.with_two_columns {

  400.     column-count: 1;

  401.   }

  402. }

  403. @media (min-width: 50em) {

  404.   ul.with_two_columns {

  405.     column-count: 2;

  406.   }

  407. }

  408. 

  409. .gallery {

  410.   display: flex;

  411.   flex-wrap: wrap;

  412.   justify-content: space-around;

  413. }

  414.   .gallery figure img {

  415.     margin-left: 1rem;

  416.     margin-right: 1rem;

  417.   }

  418.   .gallery figure figcaption {

  419.     font-family: 'ConcourseT3'

  420.   }

  421. 

  422. footer {

  423.   font-family: 'ConcourseT3';

  424.   display: flex;

  425.   flex-direction: column;

  426.   border-top: 3px solid white;

  427.   padding: 4rem 0;

  428.   background-color: #07486c;

  429.   color: white;

  430. }

  431.   footer > * {

  432.     max-width: 50rem;

  433.     margin: 0 auto;

  434.   }

  435.   footer a {

  436.     color: #f1c40f;

  437.   }

  438.   footer .avatar {

  439.     width: 200px;

  440.     height: 200px;

  441.     border-radius: 50%;

  442.     float: left;

  443.     -webkit-shape-outside: circle();

  444.     shape-outside: circle();

  445.     margin-right: 2rem;

  446.     padding: 2px 5px 5px 2px;

  447.     background: white;

  448.     border-left: 1px solid #f1c40f;

  449.     border-top: 1px solid #f1c40f;

  450.     border-right: 5px solid #f1c40f;

  451.     border-bottom: 5px solid #f1c40f;

  452.   }

  453. </style>

  454. 

  455. <h1>

  456.   <span><a id="jumper" href="#jumpto" title="Un peu perdu ?">?</a></span>

  457.   The Webflow Tech Lead Guide (archive)

  458.   <time>Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.</time>

  459. </h1>

  460. <section>

  461.   <article>

  462.     <h3><a href="https://github.com/webflow/leadership/blob/master/tech_lead.md">Source originale du contenu</a></h3>

  463.     <h2>Welcome</h2>

  464. <p>Hello! :wave: Welcome to this document. Happy to have you.</p>

  465. <p>If you've accepted a Tech Lead role, congratulations, you've demonstrated

  466. exceptional technical skills and a knack for leadership — rare qualities,

  467. indeed! Or, if you're curious about what the Tech Lead role offers and want to

  468. decide if it's right for you, you've come to the right place.</p>

  469. <p>Assuming the responsibilities of a Tech Lead is a staggering leap from the

  470. average engineer's daily routine. This guide is here to quickly help you

  471. understand the</p>

  472. <ol>

  473. <li>Definition of a successful Tech Lead</li>

  474. <li>Expectations when moving from a purely technical role to one that is a blend

  475.    of management and technical expertise, and how to manage those expectations</li>

  476. <li>Strategies to mitigate common challenges</li>

  477. <li>Stance Webflow takes on "management" <em>(hint: it's about service, not

  478.    dictatorship)</em></li>

  479. </ol>

  480. <h2>What's a Tech Lead, anyway?</h2>

  481. <p>By its most basic definition, a Tech Lead is "solely accountable for a project's

  482. success, spending 30% of their time writing code, and the other 70% managing a

  483. project". The <em>Lead</em> is no misnomer — your purpose is to navigate a team of

  484. talented engineers through choppy waters, direct them, steer them away from

  485. hazards, clear obstacles, and to keep them well fed with meaningful work.</p>

  486. <p>This is easier said than done.</p>

  487. <p>There are myriad skills a Tech Lead must possess and cultivate, but the most

  488. important are <em>sincere empathy</em>, <em>crystal clear communication</em>, and <em>technical

  489. excellence</em>. These skills are equally weighted. The Tech Lead is a "hybrid" role

  490. with one foot in management and the other in engineering, and acts as a liaison

  491. between project expectations and development tasks. A project's success is on

  492. the Tech Lead's shoulders, and it is on Webflow's shoulders to ensure they are

  493. excessively supplied with the support required to succeed.</p>

  494. <h4>Why management is different at Webflow.</h4>

  495. <p>Management has gotten a bad rap at most companies. It is often associated with

  496. treating employees as "cogs" and it conjures images of dictators with

  497. sun-eclipsing egos. This is not how Webflow operates. We view each team member

  498. as a <em>human being</em> first, and a talented contributor second. Humans need

  499. relationships built on compassion and cooperation. It is the Tech Lead's job to

  500. foster such an environment, and such environments are engendered through an

  501. attitude of <em>service</em>.</p>

  502. <p>The Tech Lead's job is <em>not</em> to micromanage, but to be a service leader, which

  503. is to say they are there to <em>support</em> their team, to <em>serve</em> them as though they

  504. worked <em>for</em> them (not the other way around). They might be accountable for a

  505. project's success, but it is the collaborative effort <em>with</em> their team that

  506. brings a project to fruition.</p>

  507. <p>Here are some hints to help approaching how best to serve a team:</p>

  508. <ol>

  509. <li>Be direct with project needs. Do not fear to challenge your team as long as

  510.    you care deeply about their welfare.</li>

  511. <li>When successes occur, lavish your team with praise and give them credit for

  512.    everything — without them success is impossible.</li>

  513. </ol>

  514. <h2>Why might I want to be a Tech Lead?</h2>

  515. <p>You may <em>not</em> want to be a Tech Lead, and that's just fine. Webflow seeks to

  516. provide many different opportunities for engineers to advance their career,

  517. including Individual Contributor tracks that offer similar significance to

  518. advanced management roles. The Tech Lead is under more pressure than the average

  519. engineer, and it is challenging to balance the demands of managing a team and

  520. contributing code, especially when first entering the Lead role (this is

  521. completely normal, by the way).</p>

  522. <p>That said, management life can be extraordinarily rewarding. You will have input

  523. into decisions much higher up on the food chain. Your impact on Webflow's

  524. user base multiplies. You will develop clout that will reflect in your

  525. performance reviews, and subsequently, provide more opportunities for career

  526. growth. The role is often seen as a stepping stone to the title of "Senior" Engineer, as well as a prerequisite for an Engineering Manager position. You will

  527. mentor and help other engineers grow. Some find these added challenges exciting

  528. and help push <em>them</em> to new limits.</p>

  529. <h2>How can I become a tech lead?</h2>

  530. <p>Just ask! Yes, it's that easy. In your one-on-ones, express to your manager that

  531. you are interested in becoming a Tech Lead. It's your manager's duty to design a

  532. path to new roles, and, depending on your current experience, might include

  533. assigning you as a Tech Lead on your next project — and if not, then to provide

  534. you opportunities to develop the skills needed to become a Tech Lead.</p>

  535. <h2>What's expected of me when managing a team?</h2>

  536. <p>The Tech Lead's job consists of these responsibilities (in no particular order):</p>

  537. <ol>

  538. <li>To work closely with a Product Manager to set reasonable expectations around

  539.    deadlines, and to be <em>clear</em> when projects are going <em>off-track</em> (See: <a href="#help-we-are-behind-schedule">Help! We are behind schedule!</a>)</li>

  540. <li>To break up projects into digestible tasks, to tie those tasks to iterative

  541.    deliverables, and to keep track of those deliverables</li>

  542. <li>To provide ample uninterrupted work time for their team so they may

  543.    frequently enter the flow state, and to act as their team's guardian against

  544.    any potential blockers and distractions</li>

  545. <li>To ensure your team is sufficiently supplied with work at all times so that

  546.    no one "spins their wheels"</li>

  547. <li>To perform diligent code reviews, first-pass QA, and to contribute code where possible</li>

  548. <li>To be <em>available</em> to team members as they execute their tasks. (Windows of

  549.    blocked time for heads down work is expected, but windows of team

  550.    availability are expected, too)</li>

  551. <li>To occasionally work with other departments</li>

  552. </ol>

  553. <h4>Working with Other Departments</h4>

  554. <p>Product Management aligns user expectations with product features. Marketing

  555. makes those features known to the world. Support ensures Webflow makes good on those promised features. Each is critical to Webflow's continued success and growth. Engineering is at the crux of these departments and the Tech Lead acts as the liaison between them.</p>

  556. <p>The Tech Lead is responsible for communicating their project's status to other departments in two forms:</p>

  557. <ol>

  558. <li>A weekly status meeting with their team in which a dedicated Product Manager or Support Liaison* may also participate. (See: <a href="#meetings">Meetings</a>) This meeting is mandatory regardless of Product Manager or Support Liaison participation.</li>

  559. <li>A weekly "All Hands" report for the entire company to see. (See: <a href="#how-do-i-provide-status-reports-to-all-hands-and-lattice">How do I provide status reports to All Hands and Lattice?</a>)</li>

  560. </ol>

  561. <p>Some projects might not warrant a Product Manager or Support Liaison, and in these cases, the Tech Lead will express their team's status and needs to their Engineering Manager. On occasion, Marketing may also ask the Tech Lead when they should begin campaigning for a feature.</p>

  562. <p><em>* The Stabilization Team (See: <a href="#what-are-the-different-types-of-teams-a-tech-lead-can-manage">What are the different types of teams a Tech Lead can manage?</a>) will work closely with a Support Liaison to focus on fixing bugs with the greatest user impact.</em></p>

  563. <h4>Tracking Tasks</h4>

  564. <p>A great Tech Lead knows how to break a project into meaningful and easily

  565. digestible tasks (digestible means about three days scope). This gives their team members a holistic view of a project as

  566. well as a finish line, and allows the Tech Lead to assign tasks to team members

  567. each week. Breaking a project down into small tasks is a time-consuming process,

  568. and is often an ongoing effort, but is critical in providing team

  569. members with a sense of progress. It also allows the Tech Lead to create

  570. waypoints toward unknowns, and to keep those unknowns contained to small time

  571. windows (See: <a href="#task-toward-unknowns">Task toward unknowns</a>)</p>

  572. <h5>Master Tracking Issue (MTI)</h5>

  573. <p>At the onset of a project, or at the onset of a project's continuing milestones,

  574. the Tech Lead must take time to thoroughly review the project's specifications

  575. and do their best to break down the specification into trackable tasks with a scope of <strong>1-5 days</strong> of work (outside Code Review / QA), and an optimal timeline of <strong>3 days</strong>. These tasks should then be grouped into Milestones. Each Milestone is a <em>deliverable</em> with a deadline date. (See: <a href="#milestones-aka-deliverables">Milestones</a>)</p>

  576. <blockquote>

  577. <p><strong>Pro Tip</strong>: Consider enlisting your team to help you break down Milestones into tasks. This is sometimes the <em>only</em> option if you've got a team member with domain knowledge you don't possess. Delegate where it makes sense, but be sure to <em>review</em> all tasks and to <em>validate</em> their scope and/or assumptions.</p>

  578. </blockquote>

  579. <p>Webflow's current practice is to create GitHub issues for every task that are then tracked in a "Master Tracking Issue". The MTI should receive a <code>[Master Tracking Issue]</code> label in the issue's title as well as in GitHub's label section.</p>

  580. <p>The MTI is a centralized and clearly outlined view of GitHub issues that lists Milestones, their projected delivery date (See: <a href="#milestones-aka-deliverables">Milestones</a>), and their related tasks in a list that</p>

  581. <ol>

  582. <li>Can be easily assigned to your team members who will then be responsible for opening a PR to close the issue</li>

  583. <li>Displays the task's GitHub issue number <em>and</em> the PR that will close the

  584.    issue, as well as a title for the issue. This is usually best accomplished in a tabular format.</li>

  585. <li>Provides the estimated finish date for each milestone, and the status of each

  586.    issue toward those milestones (See: <a href="#displaying-progress-in-the-mti">Displaying Progress in the MTI</a>)</li>

  587. </ol>

  588. <h6>Tasks</h6>

  589. <p>Each issue (or <strong>1-5 day</strong> task) must clearly point to the portion of the specification the

  590. issue addresses <em>and</em> to the concerned areas of Webflow's codebase (if they

  591. exist). We've found it is best for each task to</p>

  592. <ol>

  593. <li>Clearly point to the original specification the issue addresses, with any

  594.    <em>visual</em> content that will help an engineer complete the task, including

  595.    screenshots/screencasts from the specification or from Webflow itself</li>

  596. <li>List a best guess of TODOs to help the engineer build a mental model around

  597.    the problems they must solve</li>

  598. </ol>

  599. <p>Below is a task template. This should be located in a GitHub issue and should receive the same title that is tracked in the MTI.</p>

  600. <blockquote>

  601. <p>Master Tracking Issue: #00000 (Place the Github link here)</p>

  602. <h3>Objective</h3>

  603. <p>List the goal of the tasks here. It does not need to be long, and can take the form of a user story, e.g. "As a user, I would like to X, so that I can X", or "As a user, I would like to be able to right-click and delete an item, so that I don't have to move my mouse all the way up to the top of the screen."</p>

  604. <h3>Tech Spec</h3>

  605. <p><Insert screenshots/wireframe/visual content of finished feature></p>

  606. <p><em>Clearly</em> outline the expectations for the tasks here. Place them in the form of TODOs. For example:</p>

  607. <ul>

  608. <li>[ ] Include a "Delete" option in the right-click menu for item</li>

  609. <li>[ ] Wire the "Delete" option to the DELETE_TEM system event</li>

  610. <li>[ ] Write unit test for delete operation</li>

  611. <li>[ ] User may <em>not</em> delete item if multiple items are selected</li>

  612. </ul>

  613. <p>Also add condition material, if needed:</p>

  614. <ul>

  615. <li>[ ] When the user is logged into a free account, disallow deletion</li>

  616. </ul>

  617. <h3>Design Artifacts</h3>

  618. <p>Provide a list of design artifacts on which the above tech spec is based. This could be an external link to an artifact the Design or UX team provided. Include authors names so that the task owner can reach out.</p>

  619. <h3>Notes</h3>

  620. <p>Any clarifying content unrelated to the above items (Or, just a word of encouragement, like "You're doing great!")</p>

  621. </blockquote>

  622. <h6>This is tough</h6>

  623. <p>Creating the Master Tracking Issue will feel like it's taking too much time and

  624. will make you question whether or not you are performing the most effective

  625. work. Trust us: it <em>is</em> critical, and the clearer the MTI, the higher likelihood

  626. of a project's success. Depending on the size of the project, it could take

  627. upwards of a week or more :scream:. It's fine. Plan for it. Make it happen. Your

  628. team will thank you. It is crucial to helping your team feel a sense of

  629. meaningful progress (See: <a href="#how-do-i-keep-my-team-motivated">How do I keep my team motivated?</a>).</p>

  630. <blockquote>

  631. <p><strong>Pro Tip:</strong> It can be helpful to keep a document open beside the spec and to

  632. write down a list of tasks before beginning the MTI. When you've got a solid

  633. brain dump of tasks, open an issue, write a basic description and highlight

  634. the specification area, and <em>then</em> go into the codebase to find where to point

  635. the issue to.</p>

  636. </blockquote>

  637. <h5>Displaying Progress in the MTI</h5>

  638. <p>You can think of the MTI as a dashboard that displays the progress of every issue associated with a  milestone. This, in turn, shows the status of <em>entire</em> milestones, and subsequently, the <em>entire</em> deliverable. For instance, here's an example of how an MTI might progress:</p>

  639. <blockquote>

  640. <h3>Legend</h3>

  641. <p>⬜️ - Hasn't started<br/>

  642. 📝 - In Progress<br/>

  643. 🔄 - Code Review / QA<br/>

  644. 🚫 - Blocked<br/>

  645. ✅ - Complete (merged into <code>dev</code>)<br/></p>

  646. <h3>Milestones</h3>

  647. <p>🏁 - BETA :: September 15, 2017<br/>

  648. 🚀 - LAUNCH :: November 1, 2017<br/></p>

  649. <p>| Milestone | Issue  |   PR   | Description                              | Progress |

  650. | :-------: | :----: | :----: | :--------------------------------------- | :------: |

  651. |    🏁     | #12650 | #12666 | Empty Interactions Panel UI Refactor     |    ✅     |

  652. |    🏁     | #12675 | #12685 | AnimationList Component                  |    🔄    |

  653. |    🏁     | #12655 | #12746 | Convert ActionListConfig to InteractionStep |    📝    |

  654. |    🚀     | #12653 | #12784 | Create InteractionConfiguration Component |    🚫    |

  655. |    🚀     | #12686 |  ???   | Create all Timed InteractionConfiguration items: Mouse Tap, Mouse Hover, Scroll Into View, Page Load, Page Scrolled |    ⬜️    |</p>

  656. </blockquote>

  657. <p>The above gives a PM (or, anyone concerned) a quick way to gauge the progress of a project. For instance, one can see the BETA milestone is about 75% complete, and since tasks are broken into roughly <strong>1-5 day</strong> increments, it is easy to tell if a milestone is going <code>off-track</code> (See: <a href="#help-we-are-behind-schedule">Help! We are behind schedule!</a>).</p>

  658. <p>It is up to the Tech Lead to maintain the status of the above MTI, though they may wish to delegate updating the status of each line item to the team member responsible for completing that issue. The important elements to display for each task are</p>

  659. <ul>

  660. <li>Its Milestone and date</li>

  661. <li>Its Issue</li>

  662. <li>Its Pull Request</li>

  663. <li>A short description</li>

  664. <li>Its Progress</li>

  665. <li>Hasn't Started</li>

  666. <li>In Progress</li>

  667. <li>Code Review</li>

  668. <li>Blocked</li>

  669. <li>Complete (merged in <code>dev</code>)</li>

  670. </ul>

  671. <blockquote>

  672. <p><strong>Pro Tip:</strong> If a single MTI grows too long and too unwieldy, it's fine to split them into separate MTIs.</p>

  673. </blockquote>

  674. <h5>Milestones (a.k.a. Deliverables)</h5>

  675. <p>The Tech Lead must keep their Product Manager (or Engineering Manager if no Product Manager is assigned) updated on how well they are tracking against Milestones, as well as provide weekly All Hands updates (See: <a href="#how-do-i-provide-status-reports-to-all-hands-and-lattice">How do I provide status reports to All Hands and Lattice?</a>). These Milestones and their respective tasks are determined by the Tech Lead and confirmed by a Product Manager, Engineering Manager, or otherwise.</p>

  676. <p>A "Milestone" is</p>

  677. <ul>

  678. <li>A <em>major</em> deliverable, usually with a six-week timeline (See: <a href="#how-long-should-projects-take">How long should projects take?</a>)</li>

  679. <li>Responsible for driving a series of tasks/issues, and is complete when <em>all</em> tasks/issues have been pushed to production</li>

  680. <li>Named according to the type of deliverable, e.g. Phase, Launch, Version (See: <a href="#types-of-milestones">Types of Milestones</a>)</li>

  681. <li>Assigned a deadline date</li>

  682. </ul>

  683. <p>The planning structure for a large project should only ever consist of two levels: Milestone -&gt; Tasks. The Milestones themselves will be under the purview of a Feature, such as Rich Content Editor or Interactions 2.0, which may take months (or years) to complete. Milestones are "chunks" of continuously delivered work, and are usually accomplished sequentially. It is rare to have a team work on Milestones in parallel unless they are highly interrelated, though some overlap is expected when moving from one Milestone to another.</p>

  684. <blockquote>

  685. <p><strong>Pro Tip:</strong> Be incredibly wary of scope increases. Scope creep is real.

  686. <em>Always</em> use a Milestone's date as the affected factor when scope changes, and

  687. clearly communicate the new scope's impact.</p>

  688. </blockquote>

  689. <p>For more info on Milestone timing, See: <a href="#how-long-should-projects-take">How long should projects take?</a></p>

  690. <h5>Types of Milestones</h5>

  691. <p>Milestones are <em>major</em> deliverables and are <em>functionally</em> the same to each other, though they can be <em>semantically</em> separated into Phases, Launches, and Versions. It's important not to dwell too much on these differences, but it can be helpful to name them accordingly for Product Managers and Marketing.</p>

  692. <p>| Term    | Definition                               |

  693. | ------- | ---------------------------------------- |

  694. | Phase   | Anything Marketing doesn't need to let users know about. These are nuts and bolts type milestones that don't introduce any major experiential changes to users. Phases take on the name of their goal, e.g. "IX2 Flux Integration", or "Storybook Components for Interactions 2.0". |

  695. | Launch  | Anything Marketing <em>needs</em> to know about so they can drum up the eyeballs. This includes alphas, betas, and official launches, and will require many weeks of lead time to prep marketing materials. |

  696. | Version | This is another version of a launch for a feature <em>that has already launched</em>. So, for IX2, after the initial launch, we labeled the subsequent launches IX2.0.1, and so on. |</p>

  697. <h5>Task toward unknowns</h5>

  698. <p>Milestones deadlines are hard to estimate, but Webflow asks that the Tech

  699. Lead do their best to place a <em>realistic</em> date on them. This constraint might

  700. seem limiting at first, but we treat deadlines more as focal points (with

  701. mitigation strategies) than immovable <em>dead</em>-lines (See: <a href="#help-we-are-behind-schedule">Help! We are behind schedule!</a>).</p>

  702. <p>Rather than rely on a Milestone's hazy, fog-covered finish line, it's much better to "task toward unknowns". Our features tend to forge new industry

  703. territory, the likes of which the JavaScript world has never seen, so it's often

  704. impossible to have a crystal ball view of upcoming work. Some of it will be

  705. clear, sure, but there will invariably be a portion of a specification that

  706. causes the best Tech Lead to scratch her head and say "Um, I have no idea how

  707. long this will take." Clear the haze. Shorten the forecast by breaking down the unknown into small tasks designed to uncover the unknown as soon as possible.</p>

  708. <p>Be adamant when prioritizing your tasks. Pivot when more information arises. Let your PM know on which of these tasks your team is currently working. Stacking these unknowns is how <em>actual</em> Milestone deadlines are discovered.</p>

  709. <blockquote>

  710. <p><strong>Pro Tip:</strong> Sometimes new tasks arise from uncovering unknowns that weren't outlined in the original MTI. It's fine to include new tasks if they are absolutely necessary to complete the Milestone. Be sure to inform your Manager if they alter the Milestone's deadline.</p>

  711. </blockquote>

  712. <h4>Meetings</h4>

  713. <p>The Tech Lead should organize one ~30-minute project meeting per week,

  714. preferably at the week's start and early in the day, whose agenda looks like the

  715. following:</p>

  716. <ol>

  717. <li>Perform a Mini-retrospective that asks:</li>

  718. <li>What went well last week?</li>

  719. <li>What didn't go so well last week?</li>

  720. <li>How can we improve what didn't go well?</li>

  721. <li>Ask each team member:</li>

  722. <li>What's the current status of your task?</li>

  723. <li>Are you blocked?</li>

  724. <li>How can I help unblock you? [<strong>Tech Lead</strong>]</li>

  725. <li>Assign new tasks to each team member</li>

  726. <li>Communicate the project's status to the Product Manager</li>

  727. <li>Answer any questions and engage in light and witty banter</li>

  728. </ol>

  729. <p>Limit team-wide meetings to this one weekly event. Hopping on a Slack call or a

  730. code pairing session should not be considered a "meeting" and should be employed

  731. liberally where needed.</p>

  732. <h4>Weekly Status</h4>

  733. <p>Every engineer is asked to report their <code>on-track</code> / <code>off-track</code> status each day

  734. to #status-frontend or #status-backend accordingly, and it is on the Tech Lead to confirm those daily (a Slack "reaction" :thumbsup: is always nice). This holds each engineer accountable to their weekly tasks and it allows the Tech Lead to step in if a task goes wildly <code>off-track</code> or beyond 5 days.</p>

  735. <blockquote>

  736. <p><strong>Pro Tip:</strong> Help your team members to focus on <em>one to three</em> concurrent tasks at a time. Any more than that is difficult to track, so offer to help reduce or combine their tasks and figure out what's causing the fragmentation.</p>

  737. </blockquote>

  738. <h4>Agile? Project Managers?</h4>

  739. <p>You may be wondering, "Where's the methodology behind this way of managing

  740. projects?". It might resemble Agile, with its two-week forecasts and weekly

  741. "Scrum"-like meetings, but it lacks burn-down charts and Scrum Masters. While we

  742. love the agile philosophy, aim to move quickly, and pivot where possible,

  743. Webflow does not subscribe to a specific methodology. This is what works for us

  744. right now, and we are always open to reevaluating it as we go. :thumbsup:</p>

  745. <h2>What are the different types of teams a Tech Lead can manage?</h2>

  746. <p>Webflow arranges its talented engineers into <em>Action</em> and <em>Permanent</em> teams for

  747. which a single Tech Lead will be responsible.</p>

  748. <p>| Team      | Description                              |

  749. | :-------- | ---------------------------------------- |

  750. | Action    | Assemble around a feature (or prototype) and disband on its completion. |

  751. | Permanent | Assemble around a domain problem and continually work on it without ever disbanding, e.g. the Performance and Stabilization teams. Tech Leads and Team Members can rotate through these teams. |</p>

  752. <h4>What size team should I expect?</h4>

  753. <p>Team sizes vary (they can even be a league of one), but the general rule is a

  754. team will include <em>three</em> members, including the Tech Lead. It is relatively

  755. easy to manage relationships with two individuals engaged in solving the same

  756. problems, but once someone is asked to manage a third, or fourth, or fifth

  757. relationship, the permutations of communication potentials grow drastically.

  758. This isn't isolated to the Tech Lead's relationship, but also to how the members

  759. of the team communicate with each other. Larger teams <em>can</em> work, but the rule

  760. of three seems to be a good starting point.</p>

  761. <p>This isn't to say a <em>team</em> must have only <em>three</em> members. An Action Team might

  762. contain seven members, including a Tech Lead who can divide the team into two

  763. groups (of three) and focus each group on parallel tasks <em>within</em> the feature's

  764. overall scope. It is then up to the Tech Lead to create a single Team Lead for

  765. each group and hold them accountable for their group's work. Bear in mind that

  766. each group should be focused on <em>feature</em> efficiency and collaborate on solving

  767. problems <em>with</em> each other so as to reduce the blocking latency commonly

  768. encountered when parallelizing individual resources.</p>

  769. <p>The aforementioned team structures can be comprised of Back-End <em>and</em> Front-End

  770. engineers. Webflow wants to blur the lines between these engineering

  771. disciplines, as well as non-engineering disciplines, e.g. designers. Forming

  772. cross-discipline teams is the end-game for feature efficiency; whether or not

  773. you pursue it is up to you and the demands of your project.</p>

  774. <h4>Team Efficiency and Organization</h4>

  775. <p>There are two ways of designing a team. One of "Feature" efficiency, which

  776. favors groups that collaborate on solving closely related problems <em>together</em>,

  777. and another of "Resource" efficiency, which favors individuals working on wholly

  778. unrelated tasks that run in parallel. Both have their strengths, but we ask that

  779. the Tech Lead optimize for <em>feature</em> efficiency where possible. See

  780. <a href="https://www.jrothman.com/mpd/agile/2015/09/resource-efficiency-vs-flow-efficiency-part-1-seeing-your-system/">Flow vs. Resource Efficiency</a>

  781. for more information. [We've replaced "Flow" with "Feature" in this article as

  782. it's easy to conflate Flow with the "Flow State"]</p>

  783. <blockquote>

  784. <p><strong>Pro Tip:</strong> Parallelization requires well-defined scope. If you are leading a

  785. project that is iterating on design specs <em>while</em> iterative development

  786. occurs, it is best to only optimize for <em>feature</em> efficiency.</p>

  787. </blockquote>

  788. <h2>Help! We are behind schedule!</h2>

  789. <p>It's cool. Really. Go grab some coffee, or get some sun, and return to your desk

  790. when your inner self reflects the same glossy sheen as a calm pond (See: <a href="#how-can-i-stay-centered">How can I stay "centered"?</a>).</p>

  791. <p>Pretty much every project encounters some unknown that threatens its delivery

  792. date. Instead of desperately trying to avoid this, try to <em>expect</em> this. You

  793. need to build it into your estimates (See: <a href="#how-can-i-make-better-estimates">How can I make better estimates?</a>).

  794. Recognize this as absolutely normal, and take comfort in the solidarity that all

  795. Tech Leads experience it. This is what separates the <em>good</em> from the <em>great</em>.</p>

  796. <p>We equate missing deadlines with heart wrenching guilt. This is a morale

  797. killer. Morale is your team's most precious resource. Instead, it's best to

  798. think of "delays" as "deferred progress", and to pitch it as such. Webflow

  799. understands Software Development is tough, so we've got some tricks up our

  800. sleeves to help you frame missing a deadline as <em>progress</em>.</p>

  801. <h4>A Word on Project Management</h4>

  802. <p>Before we dive into our <em>Rework / Defer / Abandon</em> deadline model, there are two

  803. key project management concepts that will help you understand <em>why</em> we follow

  804. it.</p>

  805. <p>First, it is important to emphasize the need to <em>tie deliverables to fixed

  806. dates</em>. Progress is hard to measure without a visible target. We must measure

  807. progress toward something, even if that something is just a guess. Progress is

  808. the lifeblood of motivation.</p>

  809. <p>Second, there are four levers you can pull to help get a project back

  810. <code>on-track</code>. They are as follows</p>

  811. <p>| Lever     | Description                              |

  812. | --------- | ---------------------------------------- |

  813. | Time      | When the deliverable is launched         |

  814. | Quality   | The craftsmanship put into the deliverable |

  815. | Resources | The number of participants contributing to the deliverable |

  816. | Scope     | The breadth of what the deliverable is and does |</p>

  817. <p>These four levers can change as a project evolves. They are the tools

  818. effective Project Managers reason with. That said, Webflow produces the highest

  819. possible quality product and will not sacrifice Quality for Time, Resources, or

  820. Scope, so we only have those three levers available to us, which we will

  821. expand on in the next section.</p>

  822. <blockquote>

  823. <p><strong>Pro Tip:</strong> The Tech Lead role is often an engineer's first foray into trying

  824. to meet the bottom-line needs of a business. Their decisions must be framed in

  825. the question: "How does this keep the company healthy?" If you've little or no

  826. business acumen, have a look at

  827. <a href="https://www.amazon.com/Personal-MBA-Master-Art-Business/dp/1591845572/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1513878441&amp;sr=1-1&amp;keywords=The+Personal+MBA">Josh Kaufman's The Personal MBA</a>.

  828. It's a fantastic crash-course in modern business practices and will help you

  829. make better decisions when considering Webflow's needs and the needs of your

  830. team.</p>

  831. </blockquote>

  832. <h4>Rework / Defer / Abandon (Mitigation Strategies for Deferred Progress)</h4>

  833. <p>You have three options when confronted with a threatened deadline that should be

  834. discussed with your Product Manager. Here they are in sorted by order of

  835. consideration:</p>

  836. <ul>

  837. <li><strong>Rework</strong> the deliverable</li>

  838. <li><strong>Defer</strong> the deadline</li>

  839. <li><strong>Abandon</strong> the project</li>

  840. </ul>

  841. <h5>Rework</h5>

  842. <p>Rework consists of asking two questions:</p>

  843. <ol>

  844. <li>Can we add resources to the project to meet the deadline?</li>

  845. <li>Can we change the scope of the deliverable to meet the deadline?</li>

  846. </ol>

  847. <p>Questioning your resources and scope should be the first tool when evaluating

  848. how to mitigate a missed deadline. Ask first if more resources can help the

  849. situation, though this is usually <strong><em>not the case</em></strong> unless the project was

  850. initially understaffed to begin with. Adding late-stage resources can

  851. <a href="https://en.wikipedia.org/wiki/The_Mythical_Man-Month">even push the deadline out farther</a>!

  852. So, your next tool is to reduce scope.</p>

  853. <blockquote>

  854. <p><strong>Pro Tip:</strong> Reducing scope is often the #1 choice when trying to hit a deadline

  855. while still providing business value. The likelihood a project requires more

  856. resources to hit a deadline is probably in the 10% range. Reduce scope 90% of

  857. the time.</p>

  858. </blockquote>

  859. <p>Reducing scope is usually feasible. As passionate software developers, we tend

  860. to bite off more than we can chew. This is your opportunity to use a fork and

  861. knife to slice up the deliverable into bite-sized pieces with more realistic

  862. expectations, and for you to communicate those expectations to other key

  863. stakeholders.</p>

  864. <h5>Defer</h5>

  865. <p>If scope cannot be reduced, and adding resources isn't an option, the next

  866. <em>best</em> option is to <em>push the deadline out</em>. Yes, you heard it right. It's to

  867. <em>move</em> the deadline. "What's the point in deadlines, then, if they can just be

  868. moved all willy-nilly?" Well, we do our best to avoid moving deadlines, but

  869. sometimes it happens, and that's totally okay. Too much is at stake when we

  870. attempt to hit an unrealistic deadline, and among them are team burnout, poor

  871. product quality, reduced morale, and more.</p>

  872. <p>The important idea here is <em>not to lose sight of a delivery date</em>. That's all

  873. that matters. Projects will fall into limbo when a missed deadline stays (ahem)

  874. dead and the project careens toward the unknown. This is <em>worse</em> than moving

  875. the deadline, so move it!</p>

  876. <h5>Abandon</h5>

  877. <p>The final and rarest option is to abandon the project altogether.

  878. Consider this if you (or another stakeholder) discover the deliverable will

  879. negatively impact the company. Scrap it! Focus on <em>efficient</em> work, not

  880. <em>productive</em> work.</p>

  881. <h5><em>An optional fourth strategy:</em> Watch it closely</h5>

  882. <p>There is a fourth option, too, when the threat of a missed deadline is no more

  883. than a subtle twang in your gut, and that is to <strong><em>watch it closely</em></strong>. Pay

  884. special attention when your intuition whispers something's off. It's important

  885. to get ahead of the problem, and this should be the moment where you

  886. preemptively strike. Make your manager aware of it.</p>

  887. <blockquote>

  888. <p><strong>Pro Tip:</strong> The key to making your and everyone else's life easier is to

  889. master the art of <em>managing expectations</em>. It is wise to under-promise and

  890. over-deliver as long as you remain candid and honest. Always state what is

  891. true. Announce worries about missing deadlines or losing a key resource.

  892. Announce wins about finishing work earlier than expected. Be as truthful as

  893. you are skeptical about unknowns.</p>

  894. </blockquote>

  895. <h2>How can I make better estimates?</h2>

  896. <p>At the time of this writing, no person has discovered a magic eight-ball

  897. estimation method for predicting software development timelines. Some might try

  898. to sell you snake-oil and tell you otherwise, and some might say it's downright

  899. impossible. It's best to accept that software estimation is rarely accurate and

  900. work from there. This is at the core of the Agile Philosophy: iterate and

  901. discover, then deliver and improve. It's an art of discovery, not an art of

  902. delivery. Webflow follows an iterative process (See: <a href="#whats-expected-of-me-when-managing-a-team">What's expected of me when managing a team?</a>) as outlined in other sections, so estimation is important, but

  903. not as important as uncovering unknowns. That said, here are some tactics to

  904. help estimate tasks:</p>

  905. <h4>Pad estimates for the unexpected</h4>

  906. <p>Development rarely unfolds as planned. Instead of <em>precise</em> estimates, give your

  907. best guesstimate for a given task and multiply it times <strong><em>four</em></strong>, <em>especially</em>

  908. if that task involves uncovering an unknown. That might sound crazy — and

  909. sometimes it is; experience helps Tech Leads refine that equation — but it's a

  910. good starting point that leaves room for dastardly unknowns.</p>

  911. <h4>Add up tasks toward unknowns</h4>

  912. <p>Once you've created your Master Tracking Issue (See: <a href="#whats-expected-of-me-when-managing-a-team">What's expected of me when managing a team?</a>), you can get a sense of how long the project might take. Be

  913. sure to identify which tasks are associated with <em>discovery</em> (finding unknowns),

  914. and which have more concrete definitions. Once you've completed all the

  915. discovery tasks, you will have a <em>much</em> better sense of the deadline's

  916. accuracy.</p>

  917. <h4>The 80/20 Rule</h4>

  918. <p>It is easy to overlook time-consuming nuances that slow the final 20% of a

  919. project. When you view your project holistically, break it up using the 80/20

  920. rule, and consider that the final 20% of a project might account for <em>another</em>

  921. 80% of the overall timeline. There are a number of reasons for this, but the

  922. final 20% is often filled with polishing the deliverable, and complex features

  923. require polish for <em>every</em> feature and edge case, which compounds near the

  924. project's end.</p>

  925. <p>What does this mean for you? Just treat the 80% point in your project as the

  926. halfway marker. That will align expectations against the added effort nuance

  927. prescribes.</p>

  928. <h4>Never forget QA</h4>

  929. <p>When you estimate deadlines, set a date for <em>code completion</em> so that QA can

  930. have time to discover any bugs or UX issues. Your estimates must consider this

  931. extra phase, and to consider QA's current workload.</p>

  932. <h4>Cooldown: Bug fixes after delivery</h4>

  933. <p>On delivery, plan to leave some time to fix any immediate bugs before starting new milestones. The amount of time can vary based on the deliverable's complexity, and a week is usually a good window. This is an opportunity to give your team some downtime before leaping into the next set of tasks, and it gives you a chance to tighten up the next milestone's MTI.</p>

  934. <h2>How long should projects take?</h2>

  935. <p>While the scope of a feature might require months and months of work, its

  936. versioned <em>milestones</em> should aim for six-week timelines, including QA, so each

  937. milestone is <em>code complete</em> around four weeks. This allows Marketing to

  938. evaluate a <em>proven</em> set of features and put them in their pocket, so to speak,

  939. and queue them for announcement based on market trends. Breaking a large feature

  940. into six-week timelines can appear challenging at first, but we ask this for a

  941. few important reasons:</p>

  942. <ol>

  943. <li>It is much easier to reason about smaller scope and timelines</li>

  944. <li>It allows projects to pivot if its business value somehow proves meager</li>

  945. <li>It allows groups of three to move faster</li>

  946. </ol>

  947. <p>A six-month project's <em>major</em> Milestones may then look like this:</p>

  948. <ol>

  949. <li>Alpha Launch (6 weeks)</li>

  950. <li>Beta Launch (6 weeks)</li>

  951. <li>Feature Launch v1.0 (6 weeks)</li>

  952. <li>Feature Launch v1.0.1 (6 weeks) :checkered_flag:</li>

  953. </ol>

  954. <h2>Should I branch off of feature branches or not?</h2>

  955. <p>Not.*</p>

  956. <p>Do not branch off of <code>feature-branches</code>. Tech Leads should aim to have their team commit their <code>feature-branches</code> directly to <code>dev</code> rather than to another <code>feature-branch</code> that is kept up-to-date with <code>dev</code>. Long-lived <code>feature-branches</code> often introduce code dependencies and other programming

  957. patterns that require cherry-picking and other <em>hard-to-keep-in-sync-with-other-branches</em> issues. Instead, the Tech Lead should place their project behind a <em>Feature Flag</em> and continually merge it with <code>dev</code>.</p>

  958. <p>To summarize, Webflow has two <em>main</em> branches:</p>

  959. <ol>

  960. <li><code>dev</code></li>

  961. <li><code>master</code></li>

  962. </ol>

  963. <p>And a <code>feature-branch</code></p>

  964. <ol>

  965. <li>May branch from: <code>dev</code></li>

  966. <li>Must merge back into: <code>dev</code></li>

  967. </ol>

  968. <h5>Feature flags</h5>

  969. <p>We encourage all of our engineers to push code every day (if possible), and to

  970. prevent a new feature from stepping on the toes of our users, we suggest Tech

  971. Leads place those new features behind a "Feature Flag" that can be toggled with

  972. the

  973. ShortcutHelper.</p>

  974. <blockquote>

  975. <p>*Okay, there <em>might</em> be a case for a long-lived branch to which other branches commit. And by "might", we mean maybe 1% of the time where we must refactor a critical, widely-used portion of our infrastructure. So, basically never. :smile: Should the need for such a branch arise, please inform the <em>entire</em> team, your product manager, and your engineering manager of your intent. You may be surprised about how the work could be organized into smaller, continually merged branches.</p>

  976. </blockquote>

  977. <h2>How can I stay "centered"?</h2>

  978. <p>Staying "centered" means you take care of yourself first and foremost and find a

  979. "happy" place from which to approach solving problems. Life is about performing

  980. as much meaningful work as it is about performing meaningful <em>human activities</em>.

  981. This means you will need to take a break from your daily tasks and engage in

  982. activities that keep you fresh and focused. Does reading a book help you? Does

  983. binge-watching some Netflix? Does exercise? Fresh air? Find a routine that keeps

  984. you on point in work <em>and</em> in life, and don't be afraid to express those needs

  985. to your manager, and never fear to make time for them, even if it feels like it's

  986. cutting into your productivity.</p>

  987. <p>If you aren't centered, your team won't be centered. Lead by example.</p>

  988. <h2>How do I stay organized?</h2>

  989. <p>New Tech Leads feel overwhelmed, and if they don't, then they probably aren't

  990. performing some part of their job. :sweat_smile: (Okay, fine, some of us may be

  991. able to take the role in stride, but it's uncomfortable for most). The key

  992. to mitigating the dreaded stress of <em>too much</em>, is to learn the art of time

  993. management. This can take shape in many ways, and it boils down to your own

  994. preferences. If you've never picked up a book on time management, we recommend

  995. starting with

  996. <a href="ttps://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0143126563/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1513878379&amp;sr=1-1&amp;keywords=Getting+Things+Done">David Allen's Getting Things Done</a>.

  997. It's a great first step to learning how to transfer the cacophony of noise in

  998. your head elsewhere. If his method doesn't work for you, seek to find another

  999. and share it when you do.</p>

  1000. <h2>How much should I expect to code?</h2>

  1001. <p>This depends on the project, but a good estimate is that you will code 30% of

  1002. the time (if not fewer), <em>review</em> code 30% of the time (if not more), and serve

  1003. your team with your remaining time.</p>

  1004. <h4>Code Reviews</h4>

  1005. <p>Since you are ultimately responsible for the quality of the deliverable, you

  1006. will want to review and sign off on every PR. This can be incredibly time

  1007. consuming on larger teams, so it's good to encourage your team to review <em>each

  1008. other's</em> code. That said, expect to perform <em>a lot</em> of code reviews, and look at

  1009. them as an opportunity to mentor junior team members, and with senior team

  1010. members, to keep you on top of your skills.</p>

  1011. <h2>How do I provide status reports to All Hands and Lattice?</h2>

  1012. <p>Every Thursday at 11am PST (as of this writing), Webflow holds an "All Hands" meeting where

  1013. the management team relays the status of all of Webflow's ongoing projects as well as large company goals and initiatives. It is the Tech Lead's responsibility to provide a progress update for their

  1014. project to the Webflow Project Tracker Google document <em>prior</em> to this

  1015. meeting. This document is shared in the #all-hands channel in Slack. A template for the updates is located at the end of the Google document. Please follow it accordingly. The items in the template are</p>

  1016. <ol>

  1017. <li>TDLR, or a brief blurb on the project's state of affairs.</li>

  1018. <li>MILESTONE ON-TRACK/OFF-TRACK, where you provide the track updates for each active milestone, their percent progess, and the percent change from the previous week (these are guesstimates). Also list out the next two weeks of tasks the team will work on and their expected delivery dates.</li>

  1019. <li>KEY DECISIONS, where you mention any big key decisions that lead to timeline changes, scope changes, and anything that relates to support/marketing, or change in resources.</li>

  1020. <li>RISKS, UNKNOWNS, AND BLOCKERS, where you mention any risks, unknowns, or blockers that appeared since the last week.</li>

  1021. </ol>

  1022. <h4>Lattice</h4>

  1023. <p>Webflow uses Lattice to help track higher level company goals. In addition to your weekly All Hands updates, we will ask that you also update any Lattice goals that are assigned to you. If you do not have an account, reach out to your Engineering Manager for help.</p>

  1024. <h2>How do I keep my team motivated?</h2>

  1025. <p>Engendering a sense of progress, and giving sufficient room for creative problem

  1026. solving without dictating <em>how</em>, motivates humans more than money, or any carrot

  1027. and stick. We are intrinsically motivated creatures with simple heuristics: If

  1028. you place realistic goals in front of us, the tools to do it, and a sense of

  1029. purpose for why we should, we will move mountains.</p>

  1030. <p>Science has given us some key insights into what motivates humans. Many of the

  1031. concepts in this document are built on top of those insights, so you've already

  1032. been employing tactics to keep your team motivated! That said, here are some of

  1033. the underlying mechanics of our process.</p>

  1034. <h4>Autonomy, Mastery, and Purpose</h4>

  1035. <p>Daniel Pink, in his book

  1036. <a href="https://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1513878328&amp;sr=1-1&amp;keywords=drive+daniel+pink">Drive</a>,

  1037. dispelled the myth that humans are extrinsically motivated, or that is to say

  1038. motivated by <em>external</em> factors such as money or nicer offices, job titles, etc.

  1039. Instead, he found that we are motivated by <em>internal</em> (or intrinsic)

  1040. factors, such as a being given a sense of belonging, opportunities to grow

  1041. skills, and to do so on our own terms. These three intrinsic factors can be

  1042. boiled down to Autonomy, Mastery, and Purpose, and are excellent starting points

  1043. for dissecting the basics of motivation.</p>

  1044. <p>Part of providing these key motivators falls on Webflow's shoulders, but a

  1045. clever Tech Lead can use them to great effect, too. So, every week ask yourself

  1046. these questions:</p>

  1047. <ol>

  1048. <li>Am I giving my team enough room to solve problems on their own terms? Am I

  1049.    dishing out commands when I should be providing direction and intent?

  1050.    [<strong>Autonomy</strong>]</li>

  1051. <li>Am I placing my team members on the right tasks that can help them grow?

  1052.    [<strong>Mastery</strong>]</li>

  1053. <li>Am I aligning <em>why</em> we are building this feature with <em>how</em> Webflow wants to

  1054.    help the world? [<strong>Purpose</strong>]</li>

  1055. </ol>

  1056. <h4>Provide Feedback</h4>

  1057. <p>Kim Scott, a Harvard grad that served as an executive at Google and Apple, sums

  1058. up how to best manage the relationships and expectations with each individual on

  1059. your team in her book

  1060. <a href="https://www.amazon.com/Radical-Candor-Kick-Ass-Without-Humanity/dp/1250103509/ref=sr_1_1?ie=UTF8&amp;qid=1513952244&amp;sr=8-1&amp;keywords=radical+candor">Radical Candor</a>.

  1061. It turns out we <em>shouldn't</em> water down how we feel and what we say to each

  1062. other, but instead we should frame tough discussions in a personal and caring

  1063. way. The basic premise of this axiom is to "Care personally, Challenge

  1064. Directly", which means you must <em>empathize</em> with your team and demonstrate to

  1065. them that you care about their welfare, but still provide them critical feedback

  1066. (that might hurt).</p>

  1067. <p>By providing critical feedback early and often, <em>and</em> by demonstrating how much

  1068. you care for people, you will sidestep catastrophic challenges later down the

  1069. road. Also, this doesn't just apply to <em>negative</em> feedback, but also <em>positive</em>

  1070. feedback, too. Both are crucial. Consider picking up her book for more

  1071. information.</p>

  1072. <blockquote>

  1073. <p><strong>Pro Tip:</strong> The way in which we <em>frame</em> feedback can make all the difference to how well it is received. Instead of attacking personal flaws, highlight the <em>behavior</em> that lead to the feedback. Consider using the Situation, Behavior, Impact model for such framing. It works like this: Bring up the situation where the behavior occurred, highlight the behavior, then mention the impact, e.g. "During today's meeting, you interrupted Brian multiple times, and made Brian feel like he couldn't speak up until the meeting's end where he presented the winning idea. This made the meeting longer than it needed to be.". Here's a <a href="https://www.mindtools.com/pages/article/situation-behavior-impact-feedback.htm">great guide</a> if you'd like to learn more.</p>

  1074. </blockquote>

  1075. <h4>Flow</h4>

  1076. <p>It's important to stress the need for each of your team members to have ample

  1077. opportunity to enter Flow. This, in and of itself, is enough to keep most people

  1078. happy at work <em>and</em> in life. It's such a critical factor in motivation and in

  1079. work <em>efficiency</em> that we've listed it here as a reminder.</p>

  1080. <h2>I have an under-performing member on my team. What do I do?</h2>

  1081. <p>Have you heard the old adage, "There are no bad employees, only bad managers?"

  1082. Well, it's mostly true. Webflow hires talented engineers, so before you

  1083. jump to any conclusions about what's wrong with an under performer, make sure

  1084. you are servicing your team 100% (See: <a href="#how-do-i-keep-my-team-motivated">How do I keep my team motivated?</a>).</p>

  1085. <p>Each team member must be sufficiently motivated through ample opportunity for

  1086. producing meaningful progress, autonomously, with room for mastery, and with a

  1087. sense of purpose. Providing continual feedback is also an essential ingredient.</p>

  1088. <p>You also must consider a team member's <em>inner work life.</em> It's okay to ask, "How

  1089. are things? Everything all right outside of work?" You <em>should</em> ask these

  1090. questions often, but remember not to pry. Give your team members room to discuss

  1091. personal issues while remembering they are <em>personal</em>.</p>

  1092. <p>If you've done your best to foster the right environment for your team member

  1093. to do their best work, and they <em>still</em> aren't meeting your expectations, have a

  1094. chat with your manager about what to do next.</p>

  1095. <h2>How can I avoid burning my team out?</h2>

  1096. <p>If a team can't meet a deadline, it's a <em>management</em> problem, and not the team's

  1097. problem. This means that, somewhere along the way, the project didn't go as

  1098. planned and a course wasn't corrected. So, <strong><em>Rule Number 1</em></strong> to avoid burnout

  1099. is "Manage the project and expectations well" (See: <a href="#help-we-are-behind-schedule">Help! We are behind schedule!</a>).</p>

  1100. <p><strong><em>Rule number 2</em></strong>: Never ask more of your team than you would ask of yourself

  1101. (and you mustn't ask yourself to work nights and weekends). Other organizations

  1102. might ask their teams to pull longer hours when the going gets rough. This is a

  1103. laser-focused bullet train to attrition and long-term inefficiencies. Webflow

  1104. cares deeply about its team, not only professionally, but personally, so we must

  1105. do our best to <em>manage our time well</em>.</p>

  1106. <h4>Crunch Time</h4>

  1107. <p>Oh, crunch time, you've haunted the best teams, and you are oh so hard to avoid.</p>

  1108. <p>As a Tech Lead, you will invariably run up against a deadline that's <em>just</em>

  1109. within reach and may require slightly more effort to push it out in the last

  1110. stretch. By <em>slightly</em>, we mean your team might need to put in a few more hours

  1111. over their 40-hour work week. Yes, that's right. Our version of "crunch" isn't

  1112. crazy hours that bleed into the evening or weekend. It's just a <em>few</em>. When

  1113. people operate at their peak performance, where they engage in the flow state

  1114. 2-4 hours a day, <em>they are incapable</em> of more work without drastic consequences.

  1115. They should already be operating at peak efficiency, and asking more of them has

  1116. severe diminishing returns and a detrimental impact to them personally, <em>and</em> to

  1117. Webflow as a company.</p>

  1118. <p>Crunch time is real. Crunch time can be a symptom of poor management. We must do

  1119. our best to limit these hyperactive periods to one or two times a year.</p>

  1120. <h2>Recommended Books</h2>

  1121. <p><a href="https://www.amazon.com/Flow-Psychology-Experience-Perennial-Classics/dp/0061339202/ref=sr_1_1?ie=UTF8&amp;qid=1513878317&amp;sr=8-1&amp;keywords=flow">Flow</a></p>

  1122. <p><a href="https://www.amazon.com/Deep-Work-Focused-Success-Distracted/dp/1455586692/ref=sr_1_1?ie=UTF8&amp;qid=1515804941&amp;sr=8-1&amp;keywords=deep+work">Deep Work</a></p>

  1123. <p><a href="https://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1513878328&amp;sr=1-1&amp;keywords=drive+daniel+pink">Drive</a></p>

  1124. <p><a href="https://www.amazon.com/Leaders-Eat-Last-Together-Others/dp/1591848016/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1513878339&amp;sr=1-1&amp;keywords=Leaders+Eat+Last">Leaders Eat Last</a></p>

  1125. <p><a href="https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1513878350&amp;sr=1-1&amp;keywords=The+Manager%27s+Path">The Manager's Path</a></p>

  1126. <p><a href="https://www.amazon.com/Progress-Principle-Ignite-Engagement-Creativity/dp/142219857X/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1513878365&amp;sr=1-1&amp;keywords=The+Progress+Principle">The Progress Principle</a></p>

  1127. <p><a href="https://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0143126563/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1513878379&amp;sr=1-1&amp;keywords=Getting+Things+Done">Getting Things Done</a></p>

  1128. <p><a href="https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Without/dp/0143118757/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1513878391&amp;sr=1-1&amp;keywords=Getting+To+Yes">Getting To Yes</a></p>

  1129. <p><a href="https://www.amazon.com/Radical-Candor-Kick-Ass-Without-Humanity/dp/1250103509/ref=sr_1_1?ie=UTF8&amp;qid=1513952244&amp;sr=8-1&amp;keywords=radical+candor">Radical Candor</a></p>

  1130. <p><a href="https://www.amazon.com/Search-Inside-Yourself-Unexpected-Achieving-ebook/dp/B0070XF474/ref=sr_1_1?s=digital-text&amp;ie=UTF8&amp;qid=1513878403&amp;sr=1-1&amp;keywords=Search+Inside+Yourself">Search Inside Yourself</a></p>

  1131. <p><a href="https://www.amazon.com/Discover-Your-Strengths-Marcus-Buckingham/dp/0743201140/ref=sr_1_1?ie=UTF8&amp;qid=1513878430&amp;sr=8-1&amp;keywords=Now+Discover+Your+Strengths">Now Discover Your Strengths</a></p>

  1132. <p><a href="https://www.amazon.com/Personal-MBA-Master-Art-Business/dp/1591845572/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1513878441&amp;sr=1-1&amp;keywords=The+Personal+MBA">The Personal MBA</a></p>

  1133.   </article>

  1134. </section>

  1135. 

  1136. 

  1137. <nav id="jumpto">

  1138.   <p>

  1139.     <a href="/david/blog/">Accueil du blog</a> |

  1140.     <a href="https://github.com/webflow/leadership/blob/master/tech_lead.md">Source originale</a> |

  1141.     <a href="/david/stream/2019/">Accueil du flux</a>

  1142.   </p>

  1143. </nav>

  1144. 

  1145. <footer>

  1146.   <div>

  1147.     <img src="/static/david/david-larlet-avatar.jpg" loading="lazy" class="avatar" width="200" height="200">

  1148.     <p>

  1149.       Bonjour/Hi!

  1150.       Je suis <a href="/david/" title="Profil public">David&nbsp;Larlet</a>, je vis actuellement à Montréal et j’alimente cet espace depuis 15 ans. <br>

  1151.       Si tu as apprécié cette lecture, n’hésite pas à poursuivre ton exploration. Par exemple via les <a href="/david/blog/" title="Expériences bienveillantes">réflexions bimestrielles</a>, la <a href="/david/stream/2019/" title="Pensées (dés)articulées">veille hebdomadaire</a> ou en t’abonnant au <a href="/david/log/" title="S’abonner aux publications via RSS">flux RSS</a> (<a href="/david/blog/2019/flux-rss/" title="Tiens c’est quoi un flux RSS ?">so 2005</a>).

  1152.     </p>

  1153.     <p>

  1154.       Je m’intéresse à la place que je peux avoir dans ce monde. En tant qu’humain, en tant que membre d’une famille et en tant qu’associé d’une coopérative. De temps en temps, je fais aussi des <a href="https://github.com/davidbgk" title="Principalement sur Github mais aussi ailleurs">trucs techniques</a>. Et encore plus rarement, <a href="/david/talks/" title="En ce moment je laisse plutôt la place aux autres">j’en parle</a>.

  1155.     </p>

  1156.     

  1157.     <p>

  1158.       Voici quelques articles choisis :

  1159.       <a href="/david/blog/2019/faire-equipe/" title="Accéder à l’article complet">Faire équipe</a>,

  1160.       <a href="/david/blog/2018/bivouac-automnal/" title="Accéder à l’article complet">Bivouac automnal</a>,

  1161.       <a href="/david/blog/2018/commodite-effondrement/" title="Accéder à l’article complet">Commodité et effondrement</a>,

  1162.       <a href="/david/blog/2017/donnees-communs/" title="Accéder à l’article complet">Des données aux communs</a>,

  1163.       <a href="/david/blog/2016/accompagner-enfant/" title="Accéder à l’article complet">Accompagner un enfant</a>,

  1164.       <a href="/david/blog/2016/senior-developer/" title="Accéder à l’article complet">Senior developer</a>,

  1165.       <a href="/david/blog/2016/illusion-sociale/" title="Accéder à l’article complet">L’illusion sociale</a>,

  1166.       <a href="/david/blog/2016/instantane-scopyleft/" title="Accéder à l’article complet">Instantané Scopyleft</a>,

  1167.       <a href="/david/blog/2016/enseigner-web/" title="Accéder à l’article complet">Enseigner le Web</a>,

  1168.       <a href="/david/blog/2016/simplicite-defaut/" title="Accéder à l’article complet">Simplicité par défaut</a>,

  1169.       <a href="/david/blog/2016/minimalisme-esthetique/" title="Accéder à l’article complet">Minimalisme et esthétique</a>,

  1170.       <a href="/david/blog/2014/un-web-omni-present/" title="Accéder à l’article complet">Un web omni-présent</a>,

  1171.       <a href="/david/blog/2014/manifeste-developpeur/" title="Accéder à l’article complet">Manifeste de développeur</a>,

  1172.       <a href="/david/blog/2013/confort-convivialite/" title="Accéder à l’article complet">Confort et convivialité</a>,

  1173.       <a href="/david/blog/2013/testament-numerique/" title="Accéder à l’article complet">Testament numérique</a>,

  1174.       et <a href="/david/blog/" title="Accéder aux archives">bien d’autres…</a>

  1175.     </p>

  1176.     <p>

  1177.       On peut <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">échanger par courriel</a>. Si éventuellement tu souhaites que l’on travaille ensemble, tu devrais commencer par consulter le <a href="http://larlet.com">profil dédié à mon activité professionnelle</a> et/ou contacter directement <a href="http://scopyleft.fr/">scopyleft</a>, la <abbr title="Société coopérative et participative">SCOP</abbr> dont je fais partie depuis six ans. Je recommande au préalable de lire <a href="/david/blog/2018/cout-site/" title="Attention ce qui va suivre peut vous choquer">combien coûte un site</a> et pourquoi je suis plutôt favorable à une <a href="/david/pro/devis/" title="Discutons-en !">non-demande de devis</a>.

  1178.     </p>

  1179.     <p>

  1180.       Je ne traque pas ta navigation mais mon

  1181.       <abbr title="Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33.184162340">hébergeur</abbr>

  1182.       conserve des logs d’accès.

  1183.     </p>

  1184.   </div>

  1185. </footer>

  1186. <script type="text/javascript">

  1187.   ;(_ => {

  1188.     const jumper = document.getElementById('jumper')

  1189.     jumper.addEventListener('click', e => {

  1190.       e.preventDefault()

  1191.       const anchor = e.target.getAttribute('href')

  1192.       const targetEl = document.getElementById(anchor.substring(1))

  1193.       targetEl.scrollIntoView({behavior: 'smooth'})

  1194.     })

  1195.   })()

  1196. </script>