recentpopularlog in

andrewsardone : team   39

The Complexity Trap: Think Before You Leap - Daniel Westheide
imagine the unthinkable for a minute: What if we did server-side rendering of HTML instead? There wouldn’t be any need to design an evolvable JSON API, which, unlike simply exposing your domain model, is not trivial, and there would definitely be no need for defining any JSON codecs. And that’s just what you get on the server side. On the frontend side, you would have one piece of software less to maintain, you’d get faster load times and you could get rid of duplicated business logic. To sum it up, you could reduce the complexity of your frontend JavaScript code a lot.

In the words of Jorge Manrubia, who wrote a great article about how the complexity introduced by single-page applications can often be entirely avoided: “[..] what about if, instead of trying to find a solution, you put yourself in a situation where those problems don’t exist?” Eliminating problems altogether is always better than writing code to solve them, regardless of how purely functional that could is.

---
But why is it that we fall for technological solutions so often, especially ones that don’t reduce complexity at all? I think that maybe we love progrmaming too much. I was recently talking to someone about Rust, and that person said, “A language without higher-kinded types is completely useless!”. Yes, certain abstractions are not possible without them, but I have never seen a project fail due to a lack of higher-kinded types. Projects fail because the problem domain is not well understood, or because the architecture is not a good fit for the requirements. They also fail because of how the organisation is structured and because of politics, be it intra- or inter-organizational. Projects fail because of people, and because of people not talking to each other.
programming  complexity  team  bestpractices  spa  client-side  team_management  javascript 
3 days ago by andrewsardone
Figma's Engineering Values
Direct image: https://pbs.twimg.com/media/DlzhpKiUwAEPBFN.jpg


1. Communicate early and often
- Don't wait until code review to share your direction
- Solving something together is better than solving it independently
- Assume best intentions when receiving feedback

2. Prioritize impact
- We can only solve so many problems at once, so pick your battles
- Things are built with a shelf-life in mind and that's ok

3. Craftsmanship
- When solving a problem, do so sustainably
- Always strive to improve our process and learn from missteps

4. Lift your team
- Help others grow
- Strive to make people feel better, not worse
- Strive to create an inclusive culture supporting diverse opinions
- Be solution oriented
engineering  engineering_management  team  team_management  management  culture  values  is:tweet 
september 2018 by andrewsardone
Ryan Singer on Twitter re: estimation versus budgeting
Estimation requires knowing what you’re doing. That means you can estimate downhill but not uphill. You can, however, *budget* anywhere. That is, set a maximum amount of time you’re willing to spend. Budgeting != estimating.
quote  estimation  projectmanagement  software_engineering  development  is:tweet  team 
september 2018 by andrewsardone
Elided Branches: Delegation: When being helpful is actually hurting
So the next time you find yourself tempted to volunteer to take over responsibility for something from someone who reports to you, pause. Instead of taking it over, ask them what they think the next steps should be. Give your feedback, and let them bring the follow-ups to you in the next appropriate touch base. You owe it to them to stop taking over their work in the name of helpfulness.
delegation  management  time_management  productivity  team 
august 2018 by andrewsardone
Tweet on Slack being bad for technical decisions
There's nothing quite as nefarious as a technical decision made via Slack: stakeholders miss it if they're not around, points are poorly stated as they're strung across 50 half-baked thoughts, context exists across pages of jumbled noise, *and* it's time consuming.

I miss email.
team  management  communication  email  chat  slack  quote  is:tweet 
july 2018 by andrewsardone
Donut Manifesto | The importance of donuts | Lara Hogan

Years ago, I found that whenever something awesome happened in my career – maybe I got published, or promoted, or launched a project – I wouldn’t take the time to celebrate the achievement. I’m an achiever by nature, the kind who feels like every day starts at zero. Not deliberately marking these moments left me feeling like I wasn’t actually accomplishing anything. “Oh cool, that A List Apart article went up,” I would think, then move on with my day.

Once I realized that this was happening, I decided to be deliberate about marking achievements by eating one donut. Well, sometimes more than one, if it’s a really big deal. The act of donut-eating has actually helped me feel like I’m accomplishing my career goals. As I started to share this idea with more people, I found that it resonated with others, especially young career-driven women who are routinely achieving goals and furthering their career but don't take the time to note their own success.

I decided to start celebrating in a public way so that more people may be inspired to find their own ways of marking their career achievements.
productivity  motivation  fun  humor  team  management 
june 2018 by andrewsardone
Distributed “versus” HQ Org Structures – Learning By Shipping
Industry experiencing helping support [Conway's Law](https://en.wikipedia.org/wiki/Conway%27s_law)

Early on when it comes to balancing work and assigning who does what, the skills of people almost always defines who does what. […] the next derivative of this is that the overall product architecture is thus defined by the location of people. This is literally shipping the org chart, but without really deliberately deciding that.

Very tough to over-state how massive a future constraint this will be. When we say “don’t ship the org chart” baking in these architectural boundaries literally cements the path the team will take to evolve the product. Very risky while establishing P-M-Fit.

As an example, if you allocate work to people based on front-end/back-end simply because of skills and those people are remote, as you scale these teams (in terms of number of people) you are “cementing” this definition of an API between subsystems (you can take this to any level of granularity — not just UI/back end, but where data resides, how subsystems communicate, etc.). These APIs come to define not just the elegance of how a product works BUT importantly the seams to overcome and constraints in what can be done over time.

Many say things like “separate UX from back end” for ex., because those are two types of Eng. BUT where to put code is often a competitive/feature advantage not something done simply for consistency of strategy/architectural purity. Innovation breaks old notions of abstraction.

[…]

APIs seem like such an elegant and desirable approach for how remote teams work. In practice, APIs are great for external users of products to extend them because they are “contracts”. But why enforce and live with a contract internally? A role of a company can be to operate without such hard boundaries within the company. There’s a massive execution challenge that comes from building a single product composed of APIs across components. It slows innovation and builds “dependencies” across what would otherwise be “teammates”. It becomes very tough to scale and manage over time.
conways_law  team  management  product_management  engineering  engineering_management  remote-work  microservices  api 
march 2018 by andrewsardone
Three flavours of iteration

- Scientific iteration is about shipping to prioritise learning. This is where the Eric Ries Lean Startup fans hang out.

- Greedy iteration is about shipping incrementally to get the value of each increment sooner. This is where the Dan Reinertsen Cost of delay kids are.

- Defensive iteration is building incrementally parts of a whole, not for the value of any increment specifically, but so you’ve defended against having an incoherent whole when an arbitrary product cycle closes. This is the domain of “potentially shippable increment” scrum types.

In short: iteration can mean a few different things, each thing has pros and cons but misalignment is all cons, so double check you’re all aligned and be kind to each other.
via:andyfowler  team  iteration  development  product_management  agile 
february 2018 by andrewsardone
Remote Starter Kit by Hanno
Get off to a flying start as a remote team with these mighty-fine tools that are tried and tested by the Hanno team. We’ll help you to power your team’s virtual collaboration and happiness.


A good rundown of tools and processes that seemingly applies to all teams that value asynchronous communication and non-interruption, not just remote teams.
collaboration  tools  reference  remote-work  team 
february 2018 by andrewsardone
The Push Train
This is a presentation I've given about managing the human side of continuous delivery. In my experience, the challenges of deploying dozens of times per day are mostly interpersonal rather than technical.

Similarly, check out http://frequentdeploys.club/

---

Some key takeaways:
The thing you should know about writing web-driving integration tests is that doing this well is at least as hard as writing a multithreaded program. And that’s a domain where human competence isn’t estimated to be high. The other problem with testing across process boundaries is that failure is a thing that can’t be entirely avoided.

So what you tend to wind up with there is a lot of tests that work most of the time. Even if you’re really good and prevent most race conditions, you’re still going to have some defects. Given enough tests, that means that one is always failed.
We realized that the whole point of tests is to gain confidence before changing things. And to the extent that there are false negatives in the tests, or the tests gum up the works, they’re doing the opposite of that.

Tests are one way to gain some confidence that a change is safe. But that’s all they are. Just one way.

Ramping up code very gradually in production is another way
via:andyfowler  development  deployment  devops  ci  team  culture  testing  is:presentation 
february 2018 by andrewsardone
The Problem with Saying “Don’t Bring Me Problems, Bring Me Solutions”
Require problem statements instead of complaints. Although you should want people to alert you to potential issues, they need to learn how to distinguish between raising a valid concern and simply complaining. Complaints are stated in absolutes, such as always and never, rather than in concrete facts. They lack accountability and often have villains (them) and heroes (us). And they often don’t look beyond the surface of the issue. For example, “Group Blue never hits their deadlines, and we’re always left holding the bag” is a complaint. It makes an absolute statement, identifies a villain, and doesn’t show any accountability on the part of the speaker.

Problem statements, on the other hand, provide objective facts, examine underlying factors and causes, and reveal everyone’s role in creating the problem, even the person presenting it. A problem statement for the same issue would be something like this: “In the past six months, Group Blue has missed deadlines four times, by an average of 6.5 days. In two cases we were also unprepared to meet the deadline. However, in the other two cases our group completed our part of the project on time, but we had to work weekends to integrate Blue’s late work so that it wouldn’t impact the customer.”

When the issue is presented in the form of a problem statement, it’s much easier to spot the pattern of repeated delays. Because the presenters acknowledge their part in the problem, you know they’re open to being part of solution, not just blaming others. This allows everyone to dig in deeper and identify the root cause of the issue. Perhaps Group Blue needs more resources or isn’t receiving the information they need to complete their work on time. Or maybe the way projects are scheduled fails to account for unexpected events.
team  hbr  business  management  leadership 
september 2017 by andrewsardone
How To Make Use Of Weekly Design Meetings – Smashing Magazine
In a nutshell, The Design Kiosk consists of:

10 minutes for going through our current tasks and our top priorities for the company’s objectives and key results (OKR);
15 minutes for sharing the latest articles we’ve read, links we’ve found and other useful resources we’ve discovered (up to three for each member);
5 minutes for sharing a quick design tip that we learned in the past week (Photoshop, Sketch or other); for example, pressing “Alt” in a Photoshop panel displays the “Reset” button — Yipee!;
25 minutes for the main topic to be discussed (this could consist of how to adopt the latest design trends, or how to improve our presentation skills, or how to organize the style guide for our agency’s website);
5 minutes for wrapping things up, writing clear actions to be taken and deciding on the main topic for next week.
management  design  projectmanagement  team  meetings 
july 2017 by andrewsardone
The Unnecessary Fragmentation of Design Jobs
We skip most of the formal process stuff, and our Designers do everything: writing, visuals, code, project management, whatever it takes.

We’re living proof that this approach works well. We support hundreds of thousands of customers, plus multiple platforms and products, with a design team of 10 people.

We pull that off specifically because we don’t assign one designer to UX, and another to UI, and another to writing, and another to code.

Think this sounds too hard? Like there’s no way you could possibly be good at all of that?

Take a step back for a second. We’re only talking about making software.

Yes it’s hard…but in the grand scheme of things it’s not THAT hard.
design  team  product_management 
march 2017 by andrewsardone
Etsy CTO Q&A: We Need Software Engineers, Not Developers
Those people over at Etsy seem to have a good head on their collective shoulders:
[A]re you abstracting away so that you truly can say “I don’t have to worry about this”? Or are you abstracting away because you’re aware of those guts, but want to focus your attention right now in this area. That is what we’re looking for.

Post-mortem debriefings every day are littered with the artifacts of people insisting, the second before an outage, that “I don’t have to care about that.”

If “abstracting away” is nothing for you but a euphemism for “Not my job,” “I don’t care about that,” or “I’m not interested in that,” I think Etsy might not be the place for you. Because when things break, when things don’t behave the way they’re expected to, you can’t hold up your arms and say “Not my problem.” That’s what I could call “covering your ass” engineering, and it may work at other companies, but it doesn’t work here.

And the ironic part is that we find, in reality, engineers are more than willing to want to know. I’ve never heard an engineer not wanting to know more about networking. I’ve never heard an engineer wanting to say “You know what, I don’t want to care about database schema design.” And so if the reality is that people do care, then it’s kind of a waste of time to pretend that we’re abstracting away. Because you’re going to not care up until the absolute second you do, and when you do, that’s all you want to care about

Abstraction not as a means to mask complexity and shift responsibility, but to help empower you on your current problem without total naïveté. It's not an escape hatch, but a compartmentalizing tool.
software_engineering  bestpractices  abstraction  team  etsy  development  management 
december 2016 by andrewsardone
Nobel prize winner Holmström basically says sales bonuses suck
Bonuses create an incentive to close deals that might not even have the most rudimentary preconditions for success. Bonuses create an incentive to focus on closing the next deal instead of following up on the delivery of the previous one. Bonuses create a reason for sales to blame delivery and delivery to blame sales.
business  team  sales  compensation 
december 2016 by andrewsardone
Elided Branches: What do I do with my time?
Good advice for everyone:
If you use your downtime to half-bake a feature and throw it into prod for your team to support, that is harmful. If you use your downtime to wander around and interrupt your engineers who are busy working, that is harmful (and yes, I'm guilty of that sometimes!).

You are responsible for finding productive uses of downtime, and part of that is resisting the urge to meddle, micromanage, and distract your team just because you don't know what else to do. Is everything going ok? Are your teams productive, getting things done, working on the right stuff? Great! Use your time to think about the future, write a blog post, catch up on small unfinished errands. Don't worry, there will be another meeting, another fire soon enough. Enjoy it while it lasts.
team  management  productivity 
may 2016 by andrewsardone
How to fix 90% of problems at work – by @SamiHonkonen
My biggest takeaway: manage flow:
A customer request starts a process within our company that produces an end result which is of value to the customer. What should happen in between is flow. Work should flow through the organization, everyone pitching in when needed, to finish the work as quickly as possible, but without skipping on quality.

**We manage flow to serve our customers better**. As a by-product, people will be happier when they’re actually fulfilling a customer request instead of working on an item completely separated from its original context. Essentially, flow brings back the meaningfulness in our work.
productivity  team  product_management  kanban  knowledge_work  development 
january 2016 by andrewsardone
Google got it wrong. The open-office trend is destroying the workplace. - The Washington Post
This article is destined to get some link love today (2015-12-02). It heavily validates many people's (including my own) frustrations and criticisms of open-office layouts. Heavily citing a [study] (which I have not reviewed), the article packs many punches:
Meanwhile, “ease of interaction” with colleagues — the problem that open offices profess to fix — was cited as a problem by fewer than 10 percent of workers in any type of office setting.

A perfectly portioned retort to shutdown the unchallenged “collaboration” benefit.

So let's assume that these problems are real. But let's also assume that physical, group office space is valued by a company, and that there's value in having said space in dense urban areas (public transport, ”vibrancy” of the neighborhood, community building, etc.). **The article can't conclude that these companies should abandon open-office layouts.**

The study notes:
Nearly half of the surveyed workers in open offices said the lack of sound privacy was a significant problem for them and more than 30 percent complained about the lack of visual privacy.

Almost 50% of workers’ productivity is decreased because of “the lack of sound privacy”. A real problem, and **a real cost to the company.** But it's a cost that's absorbed by the company in an effort to reduce costs on the office front:
These new floor plans are ideal for maximizing a company’s space while minimizing costs.

The only way to make any change is to prove that the productivity losses exceed the savings in office space. My hunch is that's a tall order for the type of office space these companies value, but I'd love to see someone run that analysis. It's the basis of what “leaner” operations or 100% remote teams have been pushing.

Knowledge workers are familiar with [trade-offs][to].

[study]: http://www.sciencedirect.com/science/article/pii/S0272494413000340
[to]: https://en.m.wikipedia.org/wiki/Trade-off
team  productivity  office  projectmanagement 
december 2015 by andrewsardone
Move Fast and Break Nothing
move fast with a degree of caution

Building software is hard. Because yeah, moving quickly means you can do more for people. It means you can see what works and what doesn't work. It means your company sees real progress quicker.

But sometimes it's just as important to know what not to break. And when you work on those things, you change how you operate so that you can try to get the best of both worlds.

Also, try flying fighter jets sometimes. It can't be that hard.
team  learning  projectmanagement  productivity  development 
november 2015 by andrewsardone
Picard Management Tip – Delegation
Picard management tip: Give the most interesting assignments to other crew members, not yourself. That's how people stay engaged.
humor  productivity  projectmanagement  team 
november 2015 by andrewsardone
Opt-in Transparency
If, on the other hand, you allow people to opt into the full context of these discussions, you promote a healthy and sheltered creative process, but still encourage others into your discussions only if they are deeply passionate about helping you out. From the outsider’s perspective you might not care about 95% of the discussions happening in the company, but you might spend that remaining 5% on something you can genuinely pitch in and improve.

Opt-in transparency is a good balance of transparency, inclusiveness, and creative problem solving. Try to aim for those goals rather than pushing all your decision making behind closed doors. It’s a better way to create.
team  companies  projectmanagement  hr  productivity 
november 2015 by andrewsardone
Gregory Szorc's Digital Home | On Monolithic Repositories
Monolithic repositories are all about moving fast and getting things done more efficiently. In other words, monolithic repositories increase developer productivity.

Furthermore, monolithic repositories are also more compatible with the ebb and flow of large organizations and large software projects. Components, features, products, and teams come and go, merge and split. The only constant is change. And if you are maintaining separate repositories that attempt to map to this ever-changing organizational topology, you are going to have a bad time. Either you'll be constantly copying, moving, merging, splitting, etc data and repositories. Or your repositories will be organized in a very non-logical and non-intuitive manner. That translates to overhead and lost productivity. I think that monolithic repositories handle the realities of large organizations much better. Big change or reorganization you want to reflect? You can make a single, atomic, history-preserving commit to move things around. I think that's much more manageable, especially when you consider the difficulty and annoyance of history-preserving changes across repositories.


via a wrap-up of the 2015 F8 conference: http://gregoryszorc.com/blog/2015/03/28/notes-from-facebook%27s-developer-infrastructure-at-scale-f8-talk/

I love the idea of one-big repo, with the exception being open-source vs. internal projects within a company (separate repos for anything that’s open to the public).
engineering  git  mercurial  projectmanagement  team  tool 
march 2015 by andrewsardone
Open allocation - Wikipedia, the free encyclopedia
The technical term to the broader meritocracy/open project company philosophies that we're all peripherally familiar with via places like GitHub and Valve.

I did laugh at how the term was developed in a company that created Gore-Tex #seinfeld
team  productivity  projectmanagement  seinfeld 
april 2014 by andrewsardone
The one cost engineers and product managers don't consider
A well-written argument that puts complexity and development time into context of an entire product's lifespan, and the responsibility of every team member to mercilessly fight for simplicity.

Several choice quotes:
The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product. In fact, I'd argue that the initial time spent implementing a feature is one of the least interesting data points to consider when weighing the cost and benefit of a feature.
Everyone owns velocity, and the least important factor in your engineering team's velocity is how hard everyone is working. Developers need to openly discuss the complexity costs they're paying right now, those they're worried they're taking on with proposed specs, and to propose alternative product designs that can save complexity.
Your product management, QA and development teams should be using judgment to decide what should continue to exist and not just blindly adding everything that used to exist.
Software developers like challenges, and the challenge of building a complex system that serves up a simple interface is especially alluring.
Writing the lines of code is rarely the big cost in engineering: it's the understanding, the communication and the maintenance.
complexity  simplicity  technicaldebt  team  product 
july 2013 by andrewsardone
My Heroku values
Quite good. I especially like the sections on DRIs, interfaces, writing, and small apps/teams.
inspiration  productivity  work  team 
june 2013 by andrewsardone

Copy this bookmark:





to read