| On some of the infamous large public IT project failures, you just have to look at who gets the contract, how they work, and what their incentives are. (For example, don't hire management consulting partner smooth talkers, and their fleet of low-skilled seat-warmers, to do performative hours billing.) It's also hard when the team actually cares, but there are skills you can learn. Early in my career, I got into solving some of the barriers to software project management (e.g., requirements analysis and otherwise understanding needs, sustainable architecture, work breakdown, estimation, general coordination, implementation technology). But once you're a bit comfortable with the art and science of those, big new challenges are more about political and environment reality. It comes down to alignment and competence of: workers, internal team leadership, partners/vendors, customers, and investors/execs. Discussing this is a little awkward, but maybe start with alignment, since most of the competence challenges are rooted in mis-alignments: never developing nor selecting for the skills that alignment would require. |
| |
| ▲ | neilv a day ago | parent [-] | | I could blather for hours around this space. A few random highlights: * The very first thing I read about requirements was Weinberg, and it's still worth reading. (Even if you are a contracting house, with a hopeless client, and you want to go full reactive scrum participatory design, to unblock you for sprints with big blocks of billable hours, not caring how much unnecessary work you do... at least you will know what you're not doing.) * When interviewing people about business or technical, learn to use a Data Flow Diagram. You can make it accessible to almost everyone, as you talk through it, and answer all sorts of questions, at a variety of levels. There are a bunch of other system modeling tools you can use, at times, but do not underestimate the usefulness and accessibility of a good DFD. * If you can (or have to) plan at all, find and learn to use a serious Gantt chart centric planning tool (work breakdown, dependencies, resource allocations, milestones), and keep it up to date (which probably includes having it linked with whatever task-tracking tool you use, but you'll usually also be changing it for bigger-picture reasons too). Even if you are a hardware company, with some hard external-dependency milestones, you will be changing things around those unmoveables. And have everyone work from the same source of truth (everyone can see the same Gantt chart and the task * Also learn some kind of Kanban-ish board for tasking, and have it be an alternative view on the same data that's behind the Gantt view and the tasks/issues that people can/should/are working on at the moment, and anything immediately getting blocked. * In a rare disruptive startup emergency, know when to put aside Gantt, and fall back to an ad hoc text file or spreadsheet of chaos-handling prioritization that's changing multiple times per day. (But don't say that your startup is always in emergency mode and you can never plan anything, because usually there is time for a Kanban board, and usually you should all share an understanding of how those tasks fit into a larger plan, and trace back to your goals, even if it's exploratory or reactive.) * Culture of communicating and documenting, in low-friction, high-value, accessible ways. Respect it as team-oriented and professional * Avoid routine meetings; make it easy to get timely answers and discussion, as soon as possible. This includes reconsidering how accessible upper leadership should be: can you get closer to being responsive to the needs of the work on the project (e.g., if anyone needs a decision from the director/VP/etc., then quickly prep and ask, maybe with an async message, but don't wait for weekly status meeting or to schedule time on their calendar). * Avoid unnecessary process. Avoid performances. * People need blocks of time when they can get flow. Sometimes for plowing through a big chunk of stuff that only requires basic competence, and sometimes when harder thinking is required. * Be very careful with individual performance metrics. Ideally you can incentive everyone to be aligned towards team success, through monetary incentives (e.g., real equity for which they can affect the value) and through culture (everyone around you seems to work as a team, and you like that, and that inspires you). I would even start by asking if we can compensate everyone equally, shun titles, etc., and how close can we practically get to that. * Be honest about resume-driven-development. It doesn't have to be a secret misalignment. Don't let it be motivated solely as a secret goal of job-hoppers that is then lied about, or it will probably be to the detriment of your company (and also, that person will job-hop, fleeing the mess they made). If you're going to use new resume keyword framework for a project, the whole team should be honest that, say, there's elements of wanting to potentially get some win from it, wanting to trial it for possible greater use and build up organizational expertise in it, and also that it's a very conscious and honest perk for the workers to get to use the new toy. * Infosec is an unholy dumpster fire, throughout almost the entire field. Decide if you want to do better, and if so, then back it up with real changes, not CYA theatre and what someone is trying to sell you. * LeetCode frat pledging interviews select for so much misaligned thinking, and also signals that you are probably just more of the same as the low bar of our field, and people shouldn't take you seriously when you try to tell them you want to do things better. * Nothing will work well if people aren't aligned and honest. | | |
| ▲ | pas a day ago | parent | next [-] | | Many thanks for the detailed answer! How do you know when to call it quits? How do you know when people are not aligned or honest, or that you are not right for the team, or when the team is not right for the client/project? How much time is normal for a team/project to get its bearings? (It depends, I know...) For anyone else who had no idea who was https://en.wikipedia.org/wiki/Gerald_Weinberg (also known as Jerry Weinberg) also his blog is still online https://secretsofconsulting.blogspot.com/2012/09/agile-and-d... | | |
| ▲ | neilv 4 hours ago | parent | next [-] | | > How much time is normal for a team/project to get its bearings? (It depends, I know...) If you mean figure out their process, this can happen incrementally, starting simply and building up as you go, with a team of people who are open to that. It can also happen that some people come in and want to recreate the fleet of tools and best-practice processes that they know from a different company. This isn't my style, but it's not necessarily a bad idea, if everyone is onboard with that. But their prior experience might not fit the different situation (e.g., trying to do things the FAANG way in a post-ZIRP early startup). If you mean get their bearings on what they're going to build, I don't know, but it usually starts with figuring out your users'/customers' needs, and the business constraints (e.g., resources, milestones that need to be met for revenue or to get funding, etc.). If there's a new or unfamiliar technology, there might also be exploratory/learning time with that, in parallel (e.g., there's a bias that you will use certain emerging tech or an approach someone thought of, to solve what you initially suspect is the MVP problem, and you have to play with this a bit, and see what you can and can't do with it, in parallel with figuring out what problem you're actually going to solve for MVP). | |
| ▲ | neilv 5 hours ago | parent | prev [-] | | > How do you know when people are not aligned or honest, I'm not an expert on this, but do have some conventions and thoughts, so partial off-the-cuff answer... Of course, at some point, actions will speak pretty clearly about alignment or honesty. Before that, a lot of tech workers aren't deceptive by default, even if they're approaching the culture assuming a mercenary environment, and they will tell you straight what they are thinking. Maybe especially more if they think you are straight with them. I tend to think you can discuss and find common ground with these people. Some tech workers have a "California nice" persona that can obscure a few distinct categories, some fine or innocuous, one of them non-deceptive mercenary (once you start talking with them), only one of them deceptive mercenary. IMHO, just treat everyone honestly, and they will often meet you there, or often indicate when they aren't meeting you there. If you don't meet people honestly, some people will immediately adapt to that too. I think if you create an alignment-nurturing culture, and communicate and demonstrate it consistently from very first contact, you will scare away a few people, and onboard a lot of people who either are looking for that, or willing to try this unusual thing. As soon as you start introducing perverse incentives (e.g., individual performance metrics), or mercenary culture (e.g., why is this option pool so small and have worker-hostile terms), or signs of misalignment yourself, or even just sound like more of the same (e.g., "<we're-arm-fuzzy> <we're different> oh btw leetcode frat hazing bro do you even lift"), I think people will revert to the default pretty mercenary tech industry worker culture. And that's rational of them, because the worker's dominant strategy for a mutually-mercenary tech industry environment was figured out a couple decades ago, for a reason. |
| |
| ▲ | purple_basilisk 14 hours ago | parent | prev [-] | | This is an amazing summary of good advice for software projects! I literally pasted it into my notes for reference. You should write a blog or something on this topic if you don't already. | | |
| ▲ | neilv 8 hours ago | parent [-] | | Thanks for the very kind words. No blog yet. The closest thing to a blog was that I was writing a book, "Racket Tactical Field Manual" (RTFM), which would teach a programming language (Racket) and effective software engineering practices incidentally using Racket tooling, in one tractable, self-contained book (and beg Randall Munroe to do the cover illustration)... But then it looked like Racket was determined not to have commercial uptake, so I abandoned it. I suppose, if I had a software engineering blog that was fortunate to be well-received, maybe I wouldn't get 90%+ interviews wanting to give me a LeetCode frat hazing. We could instead speak like colleagues, who can see that the other person has, say, written a bunch of open source code, and skip ahead to getting a feel for more important factors about how we might work together. Instead, the signal I get is that they really, really want to do the frat hazing. (Like the AI company I just got off a successful recruiter screen with, minutes ago.) |
|
|
|
