recentpopularlog in

andrewsardone : management   18

Figma's Engineering Values
Direct image:

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
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](

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
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
Management theory is becoming a compendium of dead ideas
The theorists’ third ruling idea is that business is getting faster. There is some truth in this. Internet firms can acquire hundreds of millions of customers in a few years. But in some ways this is less impressive than earlier roll-outs: well over half of American households had motor cars just two decades after Henry Ford introduced the first moving assembly line in 1913. And in many respects business is slowing down. Firms often waste months or years checking decisions with various departments (audit, legal, compliance, privacy and so on) or dealing with governments’ ever-expanding bureaucracies. The internet takes away with one hand what it gives with the other. Now that it is so easy to acquire information and consult with everybody (including suppliers and customers), organisations frequently dither endlessly.
management  productivity  business  theory 
december 2016 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
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

Copy this bookmark:

to read