标签: Design

The Wharton School recently published an article that examines how the youngest full professor at Wharton got that way . Adam Grant's secret is to publish 5 to 10 papers a year. A book that gets on the New York Times best seller list helps as well. The article features an excerpt from the book Deep Work: Rules for Focused Success in a Distracted World that could be called "In praise of binge work.” Tim McCune is the guy that taught me the term " binge worker ." I have always been a binge worker, but this article and book bother me on several levels, as does binge work itself . First is this whole data-driven fallacy that the only figure of merit is how many papers you publish. A recent data-driven exercise was the Vietnam War, where " body count " was the metric. News flash, we lost that war. Next was my stint at Ford Motor, where the same McNamara Whiz Kids that gave us Vietnam decided "design cost" was the only pertinent metric in building a car. They demanded we engineers give them a cheap car. We did . Nobody bought the cars. The single metric was so data-driven and official. Management could amount to picking the cheapest cost out of two columns. In Web publishing, the metric is clicks. All that matters is how many clicks you get, or Facebook likes. There are click farms in Romania that will give you as many of either as you pay for. Besides this data-driven madness the whole world is descending into, there is the concept that binge work is preferable. I do it because I must. I have ADHD; it’s easy to get distracted. The way I compensate is by having OCD. I can't multitask, so I jump from binge to binge. When I told Jim Williams that my mom used to give me grief because I ate one thing at a time--first corn, then salad, then meat, then potato--he laughed, and said "My wife still gives me grief because I eat that way!" We should be careful about praising a coping mechanism. The first problem is that this "lock yourself in the office and don't pick up the phone" only works for a very narrow type of work. If you are writing the Linux kernel, or a paper that has no dependence on other people, I guess it is OK. But quite often the highest form of work is interactive, where you have to answer the phone and interact with people and stay social. Ed Fong told me that his systems work was much more social than his IC design. My dad tried to help me with my binges, saying I had to learn to multi-task. He told me, "You never get a spare 40 hours," in which you can accomplish some big task. I admit that there is a penalty to stop and restart work; you have to "pop to the stack" a bunch of stuff, and then pull it back down when you re-start. But I have learned that good documentation and notes can make this really easy. The last problem I have with binge work is that it is selfish. It means to heck with your wife, or your co-workers, or your boss. You are holed up and everyone has to leave you alone. The movie Where the Buffalo Roam shows Hunter S. Thompson shooting a fax machine that is asking when his article is going to be done—it’s way past deadline. When I saw that 30 years ago, I thought he was cool. Now I see he was a jerk. Now I am writer too. I know that there are copy editors, and managing editors, and art directors, and layout people, and they all depend on knowing when I will be done. They might accommodate me if I call or write and explain why I am late, but to just hole up and ignore the world is the sign of a narcissist sociopath, not a super-productive star. Heck, we're the analog crowd and I think there needs to be some gradient in this theory of productivity. I have dreamed of a workplace where you have to sit at picnic tables in the morning, no laptops or phones permitted, and then go into a private office with foot-thick concrete walls for the afternoon. It would combine the necessary day-to-day social interaction with the lack of distraction people like me need to get things done. I haven't read Deep Work , so maybe that is what he is really saying. "When I teach, I teach, when I write, I write, and never the two shall intermingle." It still seems like a pretty strange way to live. I have wondered if management is really being a SerDes (serializer-deserializer) , where you take a parallel requirement, like a multi-faceted project, and convert it into several serial streams to individuals who only have to worry about that one stream as it comes in. When all the individuals complete their streams, you put it back together into "parallel" form and see if it works. When I sent this post to several friends, Linear Systems president Tim McCune, who hosts the Analog Aficionado party noted, “ James Michener locked himself away in a cabin when he was serious about finishing writing a book. Shelby Foote wrote his million and half words on the Civil War with a nib pen. I'd probably be done writing a magnum opus if I'd stuck with my electric typewriter, I do feel diluted with a half-dozen screens up.” Fellow Analog Aficionado and successful author Ron Quan said, “When I write the books, I definitely become a binge worker. But after that I kick back. It is true that to get things done keeping focus is very important. However, when working with a team, it's more like what can we all do to pitch in.” How about you, are you a binge worker? Do you think it helps or hurts your design productivity and relationships with others?   Paul Rako  

Earlier this year, Juan Pablo Dellaroquelle, vice president of engineering at the Silicon Valley software company Medallia, made waves when he claimed in a blog post that good engineering managers don't exist . According to Dellaroquelle, engineers who aspire to “move up” into management aren’t good engineers -- otherwise they would have been happy in their roles -- and make even worse managers. Conversely, the best engineers may exercise influence through informal channels, but have no interest in becoming managers.   Certainly, nobody would aspire to be the pointy-haired boss from Scott Adams’ Dilbert comic strip, and as Alex Wolfe pointed out in a Design News blog, most engineers are happy in non-management roles. But is there such a thing as a good engineering manager? If so, do good engineers have the qualities necessary to be one?   I believe that good engineering managers really exist, because I’ve worked for them. (In fact, I happen to work for one right now.) I’ve also known people who were great engineers, but not-so-great engineering managers. And, of course, I’ve seen people who weren’t much good in either role.   One important thing to remember is that there’s a big difference between an engineering manager and a senior engineer. An engineering manager isn’t, or shouldn’t be, directly involved in detail-level design work. If you enjoy detail-level design work -- which you presumably do, since you chose engineering as a profession -- making this transition may be difficult. In fact, it’s the main reason why most engineers try to avoid management roles: you have to spend a lot of time doing things you don’t like (i.e. going to meetings), and little or no time doing things you like (i.e. designing innovative technical solutions).   It’s also one of the main reasons why some engineers don’t succeed as managers: the temptation to get involved in detail-level design is too great. You may be extremely bright and technically knowledgeable. However, if you’re in a management role, it’s unlikely you’re as well versed in the details of a project as the engineers who are working on it every day: they’re the ones who actually do the work. If you try to micromanage these details, not only will your engineers resent you, but, more often than not, you’ll make bad decisions. Furthermore, your engineers will make bad decisions, as they try to follow your (real or imagined) “mandates” rather than their own engineering judgment. You’re not the expert anymore, so don’t try to be.   So what should an engineering manager do? - Provide your engineers with high-level direction on project goals. - Empower them to make good decisions on their own - Don’t second-guess them, but challenge them to explain their thought processes to you. - Most importantly, find out what non-technical obstacles they’re facing, and work to address them.   Another important function of engineering managers is to communicate engineers’ work to upper management and other departments. There’s a persistent stereotype that technical people have poor communication skills, and there’s a good case to be made that engineering schools need to do a better job teaching these skills. However, good communication skills, by themselves, aren’t enough. When the 19th century Russian biologist Peter Kropotkin conducted field expeditions in Siberia, he would often take the time to explain his research to curious peasants. His aristocratic colleagues ridiculed him for trying to explain advanced biological concepts to illiterate villagers. Kropotkin replied: “You can explain anything to anyone -- provided that you understand it yourself.” As an engineering manager, you won’t be able to accurately represent your engineers’ work to upper management unless you have a strong technical understanding.   For this reason, being a good engineer is a prerequisite for being a good engineering manager. However, it’s a necessary but not sufficient condition: not every good engineer will make a good engineering manager, or even want to be one in the first place. This is why good engineering managers are few and far between. The good news is that they really exist. Furthermore, it’s something you can get better at. It’s a myth that some people are simply born to be managers. Like anything else, management and leadership skills are learned. The best engineering managers, like the best engineers, spend time trying to get better at what they do.   Readers, what do you think? Let us know in the comments section below.   About the author Dave Palmer is a licensed professional metallurgical engineer, specializing in failure analysis and materials selection. He  works as a metallurgist for a major marine engine manufacturer.  He holds a BS in Materials Science and Engineering from the Illinois Institute of Technology, and is completing his MS thesis at the University of Wisconsin-Milwaukee.

This blog focuses on sales, the critical measure of success and staying power for any company. For a company to grow and thrive, it needs to create a repeatable sales process. This means a template for a successful customer engagement can be described and taught to new sales team members. Equipped with this tool, new team members are expected to become productive in a few months.   Let's focus on what it takes to get to this level of sales maturity, which appears to be elusive for the new startup. How does an entrepreneur select the initial members of the sales team, knowing that these critical hires can make or break the company?   Setting the right context is important. When initial decisions are being made about hiring the foundation sales team, the emerging company's messaging, positioning, and ROI are not clear, refined, or even focused. That's why hiring the right person for the sales function is so vitally important to navigating the sales process.   Quite a few entrepreneurs close a few "partner" customers on their own without the help of a professional sales manager. This is often a wise choice, since it provides the entrepreneur with a direct link to the customer during the technology's early development phase. However, the entrepreneur quickly becomes a bottleneck if key roles are not delegated. The founder cannot be the CEO, vice president of engineering, super FAE, and sales manager while raising money and expect the company to grow.   Must haves The need to hire the initial sales executive will emerge early in the startup's development. What is this key team member's profile? It's the sales person who will find the right design team with the right set of problems that an unproven product may be able to handle and then traverse an imperfect situation. The product is not quite ready and needs more polish. The sales template is nonexistent. Though the course is uncharted, a good sales manager can be counted on to fill in the gaps.   The individual must have the savvy and skills to overcome this incomplete set of data by understanding the problem and solution and by determining whether there's a match between the two. He or she is the go between for the design team, RD, the FAE, and the marketing team.   Throughout the initial engagement, the sales manager can't do it alone. Well before the sales process is codified, the sales person should marshal a support system to help steer through the various shoals that arise in the first customer engagements. The sales manager will know at what stage in the sales process to bring in the various players -- the technical founder, the FAE, the marketing manager -- and the roles they are cast to perform. It's a big responsibility, but it can be vastly rewarding, because he or she is helping refine the product and messaging and, ultimately, makes the initial sales.   Closing business is the first goal, followed quickly by creating a sales process that can be replicated in other sales engagements. Once the initial accounts have been closed and the product reaches maturity, the sales manager will be able to hire and train the sales team.   A network isn't everything Savvy and persistence trumps the network in my book. It's great to have a long list of contacts and established credibility with them. These assets help open doors. But all too often, the contacts change jobs, get promoted, are assigned to other projects with different challenges, or leave engineering entirely. An impressive contacts list can become outdated quickly.   A motivated sales manager can overcome the lack of contacts with hard work by acquiring a deep understanding of the customers and by persevering beyond initial rejections. He or she should be a self-starter, since a startup won't have the resources a big company can provide. Most of the sales managers I know took a route out of engineering into application engineering and into sales. As a result, they have a grasp of the technical problem facing the design team. They learned sales through on-the-job training, and they can help fashion a solution.   I would be terribly remiss if I did not highlight the importance of the application engineers in a winning sales team's composition. The most successful sales managers rely on their FAEs who take an imperfect product, make it work in an actual customer environment, and hide all the emerging technology's warts. Meanwhile, they build relationships with the customers and identify the next opportunity.   So much of what I've written about in previous blogs applies to navigating the sales process, as well, and that means finding the right person. He or she needs sales savvy, technical expertise, excellent people and management skills, and the ability to function in an entrepreneurial environment where the rules are not yet in place. It can be a great opportunity and an exhilarating experience for the right person.   Michel Courtoy is a former design engineer and EDA executive who sits on the board of directors at Breker Verification Systems.

In this blog, let's zero in on sales, the critical measure of success and staying power for any company. For a company to grow and thrive, it needs to create a repeatable sales process. This means a template for a successful customer engagement can be described and taught to new sales team members. Equipped with this tool, new team members are expected to become productive in a few months.   Let's focus on what it takes to get to this level of sales maturity, which appears to be elusive for the new startup. How does an entrepreneur select the initial members of the sales team, knowing that these critical hires can make or break the company?   Setting the right context is important. When initial decisions are being made about hiring the foundation sales team, the emerging company's messaging, positioning, and ROI are not clear, refined, or even focused. That's why hiring the right person for the sales function is so vitally important to navigating the sales process.   Quite a few entrepreneurs close a few "partner" customers on their own without the help of a professional sales manager. This is often a wise choice, since it provides the entrepreneur with a direct link to the customer during the technology's early development phase. However, the entrepreneur quickly becomes a bottleneck if key roles are not delegated. The founder cannot be the CEO, vice president of engineering, super FAE, and sales manager while raising money and expect the company to grow.   Must haves The need to hire the initial sales executive will emerge early in the startup's development. What is this key team member's profile? It's the sales person who will find the right design team with the right set of problems that an unproven product may be able to handle and then traverse an imperfect situation. The product is not quite ready and needs more polish. The sales template is nonexistent. Though the course is uncharted, a good sales manager can be counted on to fill in the gaps.   The individual must have the savvy and skills to overcome this incomplete set of data by understanding the problem and solution and by determining whether there's a match between the two. He or she is the go between for the design team, RD, the FAE, and the marketing team.   Throughout the initial engagement, the sales manager can't do it alone. Well before the sales process is codified, the sales person should marshal a support system to help steer through the various shoals that arise in the first customer engagements. The sales manager will know at what stage in the sales process to bring in the various players -- the technical founder, the FAE, the marketing manager -- and the roles they are cast to perform. It's a big responsibility, but it can be vastly rewarding, because he or she is helping refine the product and messaging and, ultimately, makes the initial sales.   Closing business is the first goal, followed quickly by creating a sales process that can be replicated in other sales engagements. Once the initial accounts have been closed and the product reaches maturity, the sales manager will be able to hire and train the sales team.   A network isn't everything Savvy and persistence trumps the network in my book. It's great to have a long list of contacts and established credibility with them. These assets help open doors. But all too often, the contacts change jobs, get promoted, are assigned to other projects with different challenges, or leave engineering entirely. An impressive contacts list can become outdated quickly.   A motivated sales manager can overcome the lack of contacts with hard work by acquiring a deep understanding of the customers and by persevering beyond initial rejections. He or she should be a self-starter, since a startup won't have the resources a big company can provide. Most of the sales managers I know took a route out of engineering into application engineering and into sales. As a result, they have a grasp of the technical problem facing the design team. They learned sales through on-the-job training, and they can help fashion a solution.   I would be terribly remiss if I did not highlight the importance of the application engineers in a winning sales team's composition. The most successful sales managers rely on their FAEs who take an imperfect product, make it work in an actual customer environment, and hide all the emerging technology's warts. Meanwhile, they build relationships with the customers and identify the next opportunity.   So much of what I've written about in previous blogs applies to navigating the sales process, as well, and that means finding the right person. He or she needs sales savvy, technical expertise, excellent people and management skills, and the ability to function in an entrepreneurial environment where the rules are not yet in place. It can be a great opportunity and an exhilarating experience for the right person.   Michel Courtoy is a former design engineer and EDA executive who sits on the board of directors at Breker Verification Systems.

Communications between design teams have never been easier. We have real-time collaboration, video-conferencing, the cloud, virtualisation, mobility, texting, email, VoIP, and source control. Everybody is now available anywhere at any time of the day. We have the ability to track what everybody is doing and devise new ways of improving productivity. Why, then, is it still so difficult to complete System-on-a-Chip designs? The process of integrating the efforts of globally distributed design teams into a single SoC is still a daunting task. It was identified as a top challenge in a recent survey of Arteris customers, and it is easy to see why. Integration of the work of distributed teams is a major cause of delays in getting to market. Delays represent lost revenue and missed opportunity. No doubt all of these revolutionary collaboration platforms have helped the industry reduce difficulties in communication between geographically distributed design centres. They have lowered travel barriers, eroded time zone differences, and cut through geographical divides. Any company can enable its top designers to work anywhere in the world.   Geographically dispersed SoC design teams. However, bringing all that work into a final design and getting through the top level of performance and functional verification is still causing anxiety. As many devices surpass 300 million gates and 100s of IP blocks, it is easy to understand why there is complexity involved in bringing it all together. What is making global management even more difficult is the specialisation that has evolved with each design team. One team will focus on the CPU complex. Another will concentrate on the memory sub-system, and so on for graphics, video, audio, I/O, etc. As each design centre makes revisions to a specific portion of the chip, it inadvertently affects the entire SoC. Additionally, the tasks for these specialists have become more complex. The sections of each chip have become full-blown sub-systems. Complexity is on the rise, and each of these sub-systems now has multiple IPs and its own interconnect. The specialists are focused on power, performance, and area optimisations of their own sub-systems. In so doing, they focus on the verification of their portions of the SoC. Once this is complete, another team stitches all the different sub-systems together in a top-level SoC interconnect fabric. If some sub-systems are not cooperating with the rest of the chip, someone has to go back to the sub-system design teams to determine why and figure out what fix can be made. SoCs that use a hybrid bus or crossbar architecture within the interconnect fabric are particularly prone to delays in this part of the process. Bridges and shim logic are required at IP connections to make the separate sub-systems work harmoniously with each other. Reassembling these sub-systems often results in timing issues, protocol and address mismatches, and power management bugs. Many global design teams have resigned themselves to the fact that the integration stage of development is an inevitable part of the process. However, the additional time and complexity that the process adds represents lost revenue and lost opportunity. More importantly, these factors are completely avoidable. As single platform strategies gain more traction, SoC architects need ways to divide and re-assemble chips by allowing each IP sub-system design team to work independently. After each team of specialists completes its design on an individual sub-system, this new way of collaborating should re-assemble and connect all of the different sub-systems seamlessly and automatically. This enables the integrated SoC design team to complete top-level verification more quickly and get the complete chip design to market sooner. With so many means of real-time collaboration at our disposal today, design managers have to decide which ones match the needs of an organisation by asking for each one: Can it cut cost, time, and complexity? Does it help geographically dispersed teams work together more harmoniously? Can it help organise talent by expertise? Can specific tasks be assigned according to that expertise? If it could do all these things, how much would that be worth to the organisation? Design and communication tools alone cannot meet the requirements to help make design-team collaboration more efficient. Design teams need to architect SoCs with the requirements for worldwide development in mind, and use interconnect IP that enables distributed SoC development. Kurt Shuler is vice president of marketing at Arteris and has extensive IP, semiconductor, and software marketing experience in the mobile, consumer, and enterprise segments working for Intel, Texas Instruments, and three start-ups. Prior to his entry into technology, he served in the US Air Force Special Operations Forces.