8 ms·

A Tech Lead’s New Project Checklist

378 points by LeonigMig 9y ago

Domenic_S 9y ago
What’s the budget and the value proposition? should be #1. Projects without a clear purpose (happens way more than you might think) are sinking ships you've got to get away from.
- hnarayanan 9y ago
  I came here to say something similar. While one is spending their time on the first points imagining infrastructure (for usage that might one day materialise), the company goes out of business because they failed to solve a problem anyone cared about.
- sbov 9y ago
  And continually revisit it. When you're knee deep in requirements, corner cases, and industry best practices, you can lose sight of why you were building the damn thing in the first place, and end up with something that doesn't satisfy that need.
  - rprameshwor 9y ago
    Always know what 'DONE' looks like. Reminding ourselves of what the done state of project looks like helps us stay on track, from developers to the leads.
    - xchaotic 9y ago
      How do you define done? Software is never done. A better way to look at things is whether a feature is in good enough shape and whether moving on to working on other things is likely to be more beneficial.
      - HeyLaughingBoy 9y ago
        You're not building "software," you're building something for someone to use. Done is defined by what that person needs to do their work. Done should be defined up front, or at least as far ahead as possible so it's clear. One of the first questions I ask when probing about the state of a project or task is "how do you know when you're done?" Too often, the answer is a shrug, or a deer in headlights look!
- maxxxxx 9y ago
  I would add "Make sure every stakeholder has the same idea what the project will be". I have seen a lot of projects where once you talk to all stakeholders it becomes pretty clear that there is no shared understanding of what we are trying to achieve. Especially be wary of senior managers injecting their pet ideas.
  - nathancahill 9y ago
    This 1000 times. I can't tell you how often I've seen this happen. Many times it's at least a factor in failed projects. Clues this might be happening: senior managers pulling you aside to discuss their ideas for the project. Getting different questions on project updates than the goals you're building towards in scrum. Constantly changing short term goals.
  - lstamour 9y ago
    See also: https://www.youtube.com/watch?v=8fz-AowdiL8 https://www.youtube.com/watch?v=8fz-AowdiL8 - a 1 hr webinar from the folks behind Microsoft Press' recent Software Requirements books (Seilevel) on how to document these requirements and make sure folks are on the same page.
    - lstamour 9y ago
      Actually, I meant to link to https://m.youtube.com/watch?v=eYb53GvnSdQ https://m.youtube.com/watch?v=eYb53GvnSdQ which in a similar presentation covers a few more of the diagrams in a faster pace.
- mason55 9y ago
  Super important even if you're doing client based work (whether pure custom development or customizations on top of a platform). Your customers will each have their own individual pet features that they care about but if you don't drive to business value (meaning you just build whatever random shit the client tells your build) then it will be a failure 100% of the time.
tomcam 9y ago
My primary requirement is a demonstration that the site can be torn down and recovered any time – you never know when you will have a DNS problem or someone take over your domain
JackC 9y ago
"Understand the importance of the Trinity of delivery: Delivery manager, product owner, tech lead" I'm only familiar with teams too small to have separate roles like this. How does good software planning scale down to smaller teams -- say 5 or 10 people in the whole organization? Ultimately someone has to be responsible for the same concerns, but I wonder how it maps. In general I'd love to see a comparison of software teams at different sizes. What are the key, identified roles in a company of 5, 50, or 500? What are habits that smaller organizations ought to borrow from larger ones?
- 33W 9y ago
  I'm a lead on a team of 13 right now: myself, 6 developers, a QA lead, 2 testers, analyst, scrum master, and product owner. We're one of ~15? teams in my organization (part of an overall IT shop of ~3000), but we're fairly separate from the others in business and technologies. We have a delivery manager for our team and a couple other efforts. There's a dedicated tech lead of tech leads, program level PMs, lead product owner, 2 architects. There are also some other folks from the business side, change management, etc that we work with regularly. We're going through a bit of a change at the moment, removing the QA and analyst roles, spreading scrum masters across 2 teams, and limiting team size overall. So by the end of the year, I expect to have myself, the product owner, analyst is moving to scrum master, 1 QA as developer, 1 QA maybe as developer (we'll see how he adapts), and 4 developers. It is a really big organization with dedicated departments for security, security testing, application security, performance testing, accessibility testing, brand management, change & release, test data, DB, DB security, gateways, shared components. And those are only the folks I interact with - there are mainframe folks, server maintenance (linux and windows), and the list goes on. Some of that is moving to the teams now, some later. It's a pendulum though, things will be more generalized and distributed until something breaks spectacularly and someone will ask "why don't we have dedicated testers? why are we trusting every ol' dev with DB access?" and so on.
  - AndrewKemendo 9y ago
    >scrum master Serious question, do you find real value out of this position?
throwme_1980 9y ago
here is what i usually do: -identify weak people in the team with a stinky attitude, those who dont learn and are toxic, do your best to get rid of them. -next identify those mediocre people doing 9-5, maximise their output during those hours, don't give them no slack. -finally identify your super stars, cherish them, buy them coffee/lunch and give them a lot of slack. for this is a meritocracy, no damn Disneyland.
- okreallywtf 9y ago
  How do you identify superstars? Do you look at their code or do you simply see the UI when its done? I've seen a couple superstars/JS ninjas that produced unmaintainable crap, but a lot of it, and it took actually looking at their code to see why. They didn't last.
  - LaGrange 9y ago
    > How do you identify superstars? Fun to be around if you're their boss, has a confident yet subtly incorrect opinion on every single aspect of programming, climate science, dietology and immigrants that are not them, personally stabbed one of the "weaklings" in the face, knows lots of GoT trivia, "weaklings" burned out while fixing their bugs.
- strken 9y ago
  God forbid any of them gets home in time to eat dinner with their family! I can't think of anything worse than a sustainable work/life balance and employees who work the hours their contract specifies. /s
- maxxxxx 9y ago
  You seem like a nice guy to work with :)
- TheCowboy 9y ago
  You might feel like you're providing harsh yet practical advice, but you're not explaining your reasoning which is why you're getting downvoted. If you forced yourself to explain your ideas you might discover some aren't as concrete as you think, and you might strengthen some ideas that work. Posts like this have a "I have it all figured out" attitude that I would argue indicates a lack of interest in learning, and I don't think that's what you want.
anotherevan 9y ago
Unrelated minor rant: Pocket is hopeless when dealing with bullet points. It so often skips list items, especially if they have links in them. I understand that they are trying to avoid including navigation stuff, but overzealous way too often. I wish I could integrate Instapaper with my Kobo ereader instead.
dbg31415 9y ago
Ask about approved licenses and also make sure you know what you've purchased when it comes to platform service levels.
megamindbrian 9y ago
Here is the other one from today. I should turn this in to an app-style application for employers/recruiters to fill out before they contact me. https://www.sideprojectchecklist.com/marketing-checklist/ https://www.sideprojectchecklist.com/marketing-checklist/
bastijn 9y ago
Might want to add company size and team size(s). Many of these points show it is most likely for small to medium sized companies. For an enterprise the checklist does not entirely hold due to more specialized roles. Though there are some good tips.
fundabulousrIII 9y ago
How about fuck this paradigm? Scrum = Shite verbosity about agile process and training for mgmt larva. Agile = Hyperbole. AWS = I don't know better and my developers are < 35 years old or on the make (+ stock). My customers are just stupid. Security = big $$, modest skills, certs for the neglected comptia and northcut industures. I'm a CEH!! So is every script kiddie on the internet. tester: can't write working code, useless to the degree that you come in when they need you to justify junit crap numbers you generated when drunk. This will scale if 12 coors == 12 saudi virgins. analyst: I'm an experienced tester. tech lead: best resume and best bully of the bunch. I can understand stack exchange! QA: I like your doxygen docs and the test numbers but I have a problem with connecting to server(x) at ip(x) from greenland at 2pm on a sunday. Any ideas? team: Bunch of backstabbing co-moderators.
- josephearl 9y ago
  What paradigm? This just seems like a rant rather than adding any real discussion
  - fundabulousrIII 9y ago
    It is a rant and an attempt to be somewhat humorous to point out the problems and assumptions in modern 'agility'.
deleted 9y ago
[deleted]

378 points by LeonigMig 9y ago

What’s the budget and the value proposition? should be #1. Projects without a clear purpose (happens way more than you might think) are sinking ships you've got to get away from.

hnarayanan 9y ago
I came here to say something similar. While one is spending their time on the first points imagining infrastructure (for usage that might one day materialise), the company goes out of business because they failed to solve a problem anyone cared about.
sbov 9y ago
And continually revisit it. When you're knee deep in requirements, corner cases, and industry best practices, you can lose sight of why you were building the damn thing in the first place, and end up with something that doesn't satisfy that need.
- rprameshwor 9y ago
  Always know what 'DONE' looks like. Reminding ourselves of what the done state of project looks like helps us stay on track, from developers to the leads.
  - xchaotic 9y ago
    How do you define done? Software is never done. A better way to look at things is whether a feature is in good enough shape and whether moving on to working on other things is likely to be more beneficial.
    - HeyLaughingBoy 9y ago
      You're not building "software," you're building something for someone to use. Done is defined by what that person needs to do their work. Done should be defined up front, or at least as far ahead as possible so it's clear. One of the first questions I ask when probing about the state of a project or task is "how do you know when you're done?" Too often, the answer is a shrug, or a deer in headlights look!
maxxxxx 9y ago
I would add "Make sure every stakeholder has the same idea what the project will be". I have seen a lot of projects where once you talk to all stakeholders it becomes pretty clear that there is no shared understanding of what we are trying to achieve. Especially be wary of senior managers injecting their pet ideas.
- nathancahill 9y ago
  This 1000 times. I can't tell you how often I've seen this happen. Many times it's at least a factor in failed projects. Clues this might be happening: senior managers pulling you aside to discuss their ideas for the project. Getting different questions on project updates than the goals you're building towards in scrum. Constantly changing short term goals.
- lstamour 9y ago
  See also: https://www.youtube.com/watch?v=8fz-AowdiL8 https://www.youtube.com/watch?v=8fz-AowdiL8 - a 1 hr webinar from the folks behind Microsoft Press' recent Software Requirements books (Seilevel) on how to document these requirements and make sure folks are on the same page.
  - lstamour 9y ago
    Actually, I meant to link to https://m.youtube.com/watch?v=eYb53GvnSdQ https://m.youtube.com/watch?v=eYb53GvnSdQ which in a similar presentation covers a few more of the diagrams in a faster pace.
mason55 9y ago
Super important even if you're doing client based work (whether pure custom development or customizations on top of a platform). Your customers will each have their own individual pet features that they care about but if you don't drive to business value (meaning you just build whatever random shit the client tells your build) then it will be a failure 100% of the time.

tomcam 9y ago

My primary requirement is a demonstration that the site can be torn down and recovered any time – you never know when you will have a DNS problem or someone take over your domain

JackC 9y ago

"Understand the importance of the Trinity of delivery: Delivery manager, product owner, tech lead" I'm only familiar with teams too small to have separate roles like this. How does good software planning scale down to smaller teams -- say 5 or 10 people in the whole organization? Ultimately someone has to be responsible for the same concerns, but I wonder how it maps. In general I'd love to see a comparison of software teams at different sizes. What are the key, identified roles in a company of 5, 50, or 500? What are habits that smaller organizations ought to borrow from larger ones?

33W 9y ago
I'm a lead on a team of 13 right now: myself, 6 developers, a QA lead, 2 testers, analyst, scrum master, and product owner. We're one of ~15? teams in my organization (part of an overall IT shop of ~3000), but we're fairly separate from the others in business and technologies. We have a delivery manager for our team and a couple other efforts. There's a dedicated tech lead of tech leads, program level PMs, lead product owner, 2 architects. There are also some other folks from the business side, change management, etc that we work with regularly. We're going through a bit of a change at the moment, removing the QA and analyst roles, spreading scrum masters across 2 teams, and limiting team size overall. So by the end of the year, I expect to have myself, the product owner, analyst is moving to scrum master, 1 QA as developer, 1 QA maybe as developer (we'll see how he adapts), and 4 developers. It is a really big organization with dedicated departments for security, security testing, application security, performance testing, accessibility testing, brand management, change & release, test data, DB, DB security, gateways, shared components. And those are only the folks I interact with - there are mainframe folks, server maintenance (linux and windows), and the list goes on. Some of that is moving to the teams now, some later. It's a pendulum though, things will be more generalized and distributed until something breaks spectacularly and someone will ask "why don't we have dedicated testers? why are we trusting every ol' dev with DB access?" and so on.
- AndrewKemendo 9y ago
  >scrum master Serious question, do you find real value out of this position?

throwme_1980 9y ago

here is what i usually do: -identify weak people in the team with a stinky attitude, those who dont learn and are toxic, do your best to get rid of them. -next identify those mediocre people doing 9-5, maximise their output during those hours, don't give them no slack. -finally identify your super stars, cherish them, buy them coffee/lunch and give them a lot of slack. for this is a meritocracy, no damn Disneyland.

okreallywtf 9y ago
How do you identify superstars? Do you look at their code or do you simply see the UI when its done? I've seen a couple superstars/JS ninjas that produced unmaintainable crap, but a lot of it, and it took actually looking at their code to see why. They didn't last.
- LaGrange 9y ago
  > How do you identify superstars? Fun to be around if you're their boss, has a confident yet subtly incorrect opinion on every single aspect of programming, climate science, dietology and immigrants that are not them, personally stabbed one of the "weaklings" in the face, knows lots of GoT trivia, "weaklings" burned out while fixing their bugs.
strken 9y ago
God forbid any of them gets home in time to eat dinner with their family! I can't think of anything worse than a sustainable work/life balance and employees who work the hours their contract specifies. /s
maxxxxx 9y ago
You seem like a nice guy to work with :)
TheCowboy 9y ago
You might feel like you're providing harsh yet practical advice, but you're not explaining your reasoning which is why you're getting downvoted. If you forced yourself to explain your ideas you might discover some aren't as concrete as you think, and you might strengthen some ideas that work. Posts like this have a "I have it all figured out" attitude that I would argue indicates a lack of interest in learning, and I don't think that's what you want.

anotherevan 9y ago

Unrelated minor rant: Pocket is hopeless when dealing with bullet points. It so often skips list items, especially if they have links in them. I understand that they are trying to avoid including navigation stuff, but overzealous way too often. I wish I could integrate Instapaper with my Kobo ereader instead.

dbg31415 9y ago

Ask about approved licenses and also make sure you know what you've purchased when it comes to platform service levels.

megamindbrian 9y ago

Here is the other one from today. I should turn this in to an app-style application for employers/recruiters to fill out before they contact me. https://www.sideprojectchecklist.com/marketing-checklist/ https://www.sideprojectchecklist.com/marketing-checklist/

bastijn 9y ago

Might want to add company size and team size(s). Many of these points show it is most likely for small to medium sized companies. For an enterprise the checklist does not entirely hold due to more specialized roles. Though there are some good tips.

fundabulousrIII 9y ago

How about fuck this paradigm? Scrum = Shite verbosity about agile process and training for mgmt larva. Agile = Hyperbole. AWS = I don't know better and my developers are < 35 years old or on the make (+ stock). My customers are just stupid. Security = big $$, modest skills, certs for the neglected comptia and northcut industures. I'm a CEH!! So is every script kiddie on the internet. tester: can't write working code, useless to the degree that you come in when they need you to justify junit crap numbers you generated when drunk. This will scale if 12 coors == 12 saudi virgins. analyst: I'm an experienced tester. tech lead: best resume and best bully of the bunch. I can understand stack exchange! QA: I like your doxygen docs and the test numbers but I have a problem with connecting to server(x) at ip(x) from greenland at 2pm on a sunday. Any ideas? team: Bunch of backstabbing co-moderators.

josephearl 9y ago
What paradigm? This just seems like a rant rather than adding any real discussion
- fundabulousrIII 9y ago
  It is a rant and an attempt to be somewhat humorous to point out the problems and assumptions in modern 'agility'.

deleted 9y ago

[deleted]